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1.  INTRODUCTION 


1.1  Goals  and  Objectives 

This  study  was  conducted  to  determine  the  applicability  of  Logi con's 
Automated  Requirements  Engineering  (LARE)  methodology  in  the  Army 
logistics  support  environment.  Logi con  developed  LARE  to  provide  a 
means  to  define,  effectively  analyze,  and  maintain  system  require¬ 
ments.  LARE  includes  a  coherent  set  of  procedures  which  allows  ana¬ 
lysts  to  define/analyze  requirements  using  computerized  tools.  The 
Computer  Aided  Design  and  Specification  Analysis  Tool  (CADSAT)  was  used 
on  this  project.  CADSAT  was  designed  to  aid  structured  documentation 
and  analysis  of  large  processing  systems.  This  project  used  the  Air 
Force's  standard  CADSAT  with  the  CADSAT  extensions  developed  by  Logi con. 


The  study  focused  on: 

•  illustrating  the  methodology 

•  def i ni ng  LARE  procedures 

•  identifying  enhancements  to  LARE 

Normally  LARE/CADSAT  is  used  to  produce  or  validate  specifications 
for  a  system  and  its  components.  Study  objectives  did  not  however 
dwell  on  reproducing  a  set  of  documents.  Replication  of  system  docu¬ 
mentation  would  have  prevented  the  effective  evaluation  and  illustra¬ 
tion  of  LARE  technology. 
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Discussion  of  the  technical  feasibility  of  building  the  system  was 
also  excluded  from  the  study.  No  functional  or  analytical  simulations 
were  performed  to  assess  performance  requirements  with  respect  to 
timing  and  accuracy  constraints.  While  these  subjects  are  crucial  to 
system  design,  they  are  outside  the  scope  of  this  effort. 

1.2  Background 

Development  of  major  systems  is  an  increasingly  complex  problem. 

This  problem  manifests  itself  in  varying  degrees  of  successful  system 
implementations  but  has  its  roots  in  differing  perspectives.  Users, 
analysts,  developers,  and  managers  concentrate  on  that  portion  of  a 
system  for  which  they  are  directly  responsible  --  a  potentially  ex¬ 
pensive  situation.  Effective  system  implementation  demands  that 
someone  comprehend  the  total  system  under  development  to  allow  ef¬ 
fective  management  of  its  progress. 

No  completely  automated  way,  at  this  time,  can  ensure  the  absolute 
success  of  a  target  system.  This  study  addresses  one  approach  to 
reducing  the  difficulties  inherent  in  defining  complex  systems.  LARE 
centralizes  information  storage  in  a  set  of  databases.  Using  LARE  to 
model  existing  specifications  or  develop  an  initial  concept  for  an 
operational  system  will  significantly  improve  the  quality  of  the  system 
and  its  documentation,  thus  easing  the  implementation,  testing  and 
operations/maintenance  phases  of  the  project. 


LARE  developed  on  these  precepts: 

•  valid  requirements  definition  is  criti:al  to  successful 
system  implementation. 
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•  computerized  information  storage  should  be  used  to  maintain 
all  basic  data  about  a  system, 

•  selected  retrieval  of  stored  information  in  formats  suitable 
to  users  and  developers  is  essential,  and 

0  traceability  between  levels  of  system  documentation  is 
mandatory. 

Defining  a  valid  set  of  requirements  before  development  work  starts 
minimizes  system  costs.  It  is  generally  recognized  that  one  reason 
for  the  high  cost  of  systems  development  is  the  delay  in  detecting 
errors,  inconsistencies  and  omissions  in  the  requi rements/specif ica- 
ti ons. 


LAKE  prevents  some  problems  and  detects  others  early.  LARE  language 
constructs  force  analysts  to  be  precise.  The  output  reports  make 
errors,  omissions  and  inconsistencies  highly  visible. 


Storing  the  requirements  and  specifications  in  centralized  databases 
facilitates: 

0  selective  retrieval 

0  up-to-date  documentation 

0  life-cycle  maintenance 

0  standardization  of  terminology 

0  incremental  information  updates 
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Selective  retrieval  of  centrally-stored  information  allows  individuals 
on  a  project  to  get  information  pertinent  to  their  jobs.  Managers, 
analysts  and  programmers  require  different  types  of  information  to  do 
their  respective  jobs. 


Requirements  tracing  is  the  process  of  ensuring  that  all  general 
requirements  in  a  high-level  specification  have  detailed  counter¬ 
parts  in  lower-level  specification(s). 


Every  requirement  must  be  traceable  through  all  levels  of  system 
documentation  to  ensure  that  the  system  fully  meets  the  user  needs  -- 
and  that  every  stated  need  has  been  addressed  in  the  allocated  re¬ 
quirements  and  design. 


In  the  last  few  years,  both  government  and  industry  have  begun  to 
recognize  the  necessity  of  doing  thorough  requirement  analyses. 
Managers  responsible  for  the  development  of  information  systems  find 
themselves  plagued  by  poor  quality  documentation,  unstructured  re¬ 
quirements  and  specifications,  and  the  inability  to  verify  the  con¬ 
sistency  and  completeness  of  system  requirements  and  specifications. 


These  problems  begin  in  the  initial  stages  of  system  development  and 
their  impact  increases  in  terms  of  time  and  cost  over  the  system's 
life  cycle.  For  example,  inconsistent,  incomplete  requirements  foster 
inconsistent,  incomplete  specifications,  which  translate  into  design 
errors.  These  flawed  designs  are  turned  over  to  developers  who  find 
them  difficult  and  in  some  cases  impossible  to  implement. 
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In  1971,  the  Problewi  Statement  Language/Problein  Statement  Analyzer 
(PSL/PSA)  was  developed  at  the  University  of  Michigan  (Teichroew, 
Hershey  and  Sayani).  PSL/PSA  is  a  language  for  describing  system 
requirements  and  design.  The  Air  Force  acquired  a  slightly  modified 
version  called  the  User  Requirements  Language/User  Requirements 
Analyzer  (URL/URA).  URL/URA  is  also  referred  to  as  the  Computer  Aided 
Requirements  Analyzer  (CARA)  and  the  Computer-Aided  Design  and  Speci¬ 
fication  Analysis  Tool  (CADSAT). 


All  variations  of  the  tool  have  three  main  parts  and  a  common  problem. 
The  first  part  is  a  language  to  express  system  requirements.  The 
second  is  a  database  system  to  store  the  requirements.  The  third  is 
outputs/reports  to  depict  the  requirements.  All  tool  variants  lack  a 
documented  methodology  for  application. 


Logicon's  enhanced  CADSAT  is  the  result  of  an  evaluation  which  found 
URL/URA  lacking  in  the  following  areas: 

•  visibility  into  the  database(s) 

•  traceability  between  databases 

t  documentation  acceptable  by  Military  Standards 

CADSAT  therefore  differs  from  PSL/PSA  in  its  output  capabilities 
(Figure  1-1).  CADSAT  provides  a  systematic  approach  for  building 
information  systems,  but  it  soon  became  apparent  that  an  approach  to 
effectively  using  it  was  essential.  Logicon's  Automated  Requirements 
Engineering  (LARE)  methodology  was  developed  by  applying  CADSAT  over  a 
period  of  five  years  (Applications  include  programs  done  for  the  Air 
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Force,  Army,  Navy  and  other  defense/Government  agencies).  Hereafter, 
the  term  LARE  will  refer  to  both  the  tool  and  the  methodology  used  to 
apply  it. 

1.3  Summary  of  Conclusions  and  Recommendations 

Under  analysis  were  the  Standard  Army  Maintenance  System  (SAMS)  - 
Retail  Level,  Maintenance  Operations  Management  (SAMS-l/MOM)  and  the 
Maintenance  Program  Operations  Management  {SAMS-2/MP0M)  specifications, 
hereafter  known  as  the  MOM  and  the  MPOM  respectively.  The  MOM  contains 
approximately  2,100  pages.  About  85  pages  of  narrative  discuss  system 
functions  and  constraints.  Design  discussions  and  solutions  also 
appear  in  the  narrative.  The  balance  of  the  MOM  is  contained  in  nine 
annexes  which  consist  of  input/output  descriptions,  flowcharts,  decision 
tables,  file  descriptions,  information  elements,  external  interfaces, 
telecommunication  requirements,  and  a  glossary  of  terms.  MPOM  uses 
the  same  format  and  information  breakdown,  but  is  considerably  smaller. 

The  study  demonstrated  that  LARE  could  effectively  describe  both 
specifications.  Details  necessary  to  describe  both  systems  were 
translatable  into  LARE  and  representable  by  LARE  outputs.  As  analysts 
found  information  they  could  not  justify  or  information  felt  to  be 
inconsistent  or  incomplete,  Di screpancy  Reports  were  written.  Table  3-2 
and  3-3  in  the  Results  Section  summarize  the  types  of  discrepancies 
noted  and  the  number  of  discrepancies  formally  written  up. 
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Briefly,  Logicon  recommends  the  following: 

1)  Simplify  LAKE'S  man/machine  interface  by  incorporating 
user  prompts. 

2)  Improve  LAKE'S  ability  to  record  and  depict 
conditional  control  flow. 

3)  Augment  LAKE'S  ability  to  record  and  depict 
test  requirements. 

4)  Enhance  LAKE'S  database  management  system. 

5)  Apply  the  enhanced  LAKE  to  the  specification  of  an 
Army  system  from  initial  requirements  definition  through 
implementation. 
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2. 


TECHNICAL  APPROACH 


2.1  Introduction 


This  section  describes  the  technical  approach  used  in  applying  LARE  to 
the  example  Army  Detailed  Functional  System  Requirements  (DFSR). 


Figure  2-1  shows  the  basic  steps  of  the  technical  approach.  Each  of 
the  steps  is  described  within  this  section.  In  addition  to  describing 
the  procedure,  the  discussion  includes  the  rationale  underlying  deci¬ 
sions. 


The  emphasis  of  this  application  has  been  to  demonstrate  the  appli¬ 
cability  of  LARE  to  the  Army  DFSRs,  illustrate  LARE'S  strengths  and 
weaknesses,  and  document  the  experience  gained  during  the  study. 


2 . 2  Development  of  Requirements  Engineering  Plan 


At  the  beginning  of  each  project  an  individualized  set  of  appropriate 
conventions  are  developed.  This  enables  analysts  working  on  the 
project  to  move  uniformly  toward  a  common  goal.  LARE  provides  a  general¬ 
ized  methodology  applicable  to  most  system  development  cycles.  Each 
project  requires  some  tailoring  of  LARE.  Details  of  the  Require¬ 
ments  Engineering  Plan  developed  for  this  effort  appear  in  Appendix  A. 
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Figure  2-1.  Task  Overview  for  AIRMICS  Study 


UMilCOM _ 

The  first  step  of  the  project  was  familiarization  with  the  MOM  and 
MPOM  specifications.  Analysis  was  isolated  from  the  developmental 
effort  responsible  for  the  specifications.  They  were  therefore  repre¬ 
sented  based  on  several  assumptions; 

•  Both  systems  consist  of  functional  requirements 

•  These  functions  are  connected  or  interrelated  in  various 

ways 

•  The  main  purpose  of  both  systems  is  to  process  data 

•  Properties  and  values  impact  design 

After  reading  the  MOM  and  MPOM  documents,  we  split  tasks  into  major 
areas  of  concentration. 

•  Develop  evaluation  criteria.  Evaluation  criteria  were  set 

up  to  gauge  LAKE'S  ability  to  support  requirements 
engineering  (See  Table  2-1).  The  criteria  consider  only 
the  analysis  of  existing  specifications. 

•  Refine  standard  Requirements  Engineering  Plan.  The 

Requirements  Engineering  Plan  given  to  analysts  in  the 
early  stages  of  this  application  is  included  in  Annex 
A.  Specifics  of  the  plan  pertinent  to  this  project 
include:  generate  a  synonym  algorithm,  identify 
reports  to  be  produced,  and  select  CADSAT  language 
to  represent  information  in  the  specifications. 

•  Define  and  depict  functional  requirements.  Sections  2.4 

through  2.9  detail  our  approach  to  requirements  definition. 
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•  Evaluate  alternative  technologies.  Section  2.10  and  3.10 
discuss  our  brief  evaluation  of  alternative  require¬ 
ments  engineering  aids. 

2 . 3  I^e ntif ication  of  Func tional  Requirements 

Each  specification  was  reviewed  and  the  task  of  identifying  functional 
requirements  started.  At  this  stage,  analysts  searched  the  documents 
paragraph  by  paragraph  extracting  and  naming  what  they  determined  to  be 
functional  requirements  of  the  system. 

Conventions  used  for  identifying  and  naming  requirements  are  detailed 
in  the  Engineering  Plan  found  in  Appendix  A,  Section  A. 4. 

2 . 4  Analysis  of  Function al  Requirements 

Once  the  functional  requirements  of  the  systan  had  been  identified,  a 
high-level  requirements  hierarchy  was  built.  The  first  hierarchy 
emphasized  the  input,  internal,  and  output  processing  of  the  system. 

This  approach  was  used  since  the  target  system  is  a  Management  Infor¬ 
mation  System.  The  three  categories,  though  strongly  emphasized  did 
not  allow  us  to  adequately  decompose  the  system  requirements.  Because 
of  this,  a  second  hierarchy  was  built.  The  modified  structure  em¬ 
phasized  the  type  of  data  being  processed  (e.g.,  process-work-orders, 
process-task-performance-data,  maint-parts-inventory) .  The  input/output 
processing  for  each  of  these  areas  is  represented  at  a  lower  level  of 
the  system  hierarchy. 


After  finalizing  the  high-level  hierarchy,  the  detailed  functions  to  be 
performed  were  selected  and  incorporated  into  the  process  structure. 

2 . 5  Analysis  of  J) q^n trol  Requirements 

Data  and  system  control  flow  are  closely  related.  LARE  defines 
control  flow  as  the  order  in  which  system  functions  are  sequenced. 

Data  derived  by  functions  early  in  a  sequence  often  impact  the  next 
sequence  of  events.  Data  flow  (i.e.,  the  flow  of  information  into, 
through  and  out  of  the  system)  may  be  interrupted  by  system  functions 
temporarily  suspended  and  av/aiting  the  proper  control  sequence.  Data 
inputs  often  cause  spontaneous  execution  of  specific  processing. 

Primary  objectives  of  control  flow  analysis  are  to  identify: 

•  timing  relations  among  target  system  functions 

•  functions  omitted  by  previous  steps  in  the  order 

•  missed  requirements  of  a  target  system 

Due  to  the  complementary  nature  of  LARE,  control  flow  analysis  may  be 
performed  in  two  ways.  The  first  defines  a  sequence  which  initializes 
processing  at  the  point  in  the  processing  when  it  crosses  system 
boundaries.  Possible  subsequent  sequences  of  steps  or  processes 
are  recorded,  analyzed  and  inserted  in  the  database.  The  resultant 
chain  shows  all  possible  processes  that  may  be  performed,  including 
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parallel  or  mutually  exclusive  ones.  Mutually  exclusive  processes  imply 
a  decision  made  during  performance.  A  second  method  of  analysis  starts 
at  the  output  and  traces  back  through  the  internal  sequence  which 
caused  this  end  result.  This  process,  like  the  first,  yields  parallel 
and  mutually  exclusive  threads  of  process  control.  Identifying  and 
following  these  threads  through  the  system  frequently  reveals  functions 
which  were  omitted  or  input  requirements  that  had  been  overlooked. 


2.6  Analysis  of  Data  Requirements 


The  primary  objectives  of  Data  Analysis  are: 


•  identify  information  crossing  the  external  system 
boundaries 

•  determine  the  information  deciding  control  flows 

•  determine  the  outputs  requiring  inputs 


At  the  requirements  definition  stage  of  system  development,  the 
"real"  data  requirements  are  data  crossing  external  system  bound¬ 
aries.  These  data  items  must  be  defined  precisely  and  carefully 
controlled  since  they  always  impact  the  ability  of  the  target  system 
to  interface  with  other  systems. 
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Identification  of  information  required  to  determine  which  internal 
functions  the  system  will  perform  is  closely  tied  to  the  control 
flow  ancilysis.  If  this  information  is  not  provided  in  the  system, 
it  will  not  operate. 


The  third  part  of  data  requirements  analysis  determines  the  inputs 
necessary  to  produce  required  outputs.  All  too  often,  system  data 
requirements  are  unclear  or  input/output  data  are  identified  as 
"nice  to  record"  or  "nice  to  know".  As  a  result,  requirements  defi¬ 
nition  is  vague.  This  vagueness  impedes  the  development  of  an  opera¬ 
tional  system.  Required  outputs  should  first  be  justified  in  terms  of 
their  utility  to  the  user  or  other  external  system.  An  output  should 
be  specified  in  terms  of  frequency  and  accuracy  constraints.  Once  an 
output  is  deemed  required,  an  analysis  must  be  performed  to  identify 
information  elements  necessary  to  produce  the  output.  The  algo¬ 
rithm  used  to  transform  inputs  to  output  must  also  be  determined. 

The  final  inputs  identified  must  be  shown  to  be  available. 


2.7  Analysis  of  Requirements  Traceability 


Requirements  traceability  is  defined  as  the  process  of  ensuring  that 
upper-level  requirements  are  allocated  in  the  lower  levels  of  docu¬ 
mentation. 


It  was  originally  thought  that  a  traceability  analysis  could  be 
performed  between  the  MPOM  and  MOM  specifications.  Closer  examination 
of  these  specifications  showed  that  they  were  distinct  systems  to 
support  different  Army  Management  levels,  not  different  levels  of 
specification  of  the  same  system.  Although  this  analysis  could  not 
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be  perfonned  on  the  specifications  used  in  this  study,  a  discussion  of 
the  methodology  is  included  in  this  report. 


A  typical  analysis  would  trace  through  the  following  levels  of  docu¬ 
mentation: 


•  GFSR  to  DFSR 

•  DFSR  to  actual  system  test  requirements 

•  DFSR  to  the  system  design  implemented  to  meet  the  require¬ 
ments. 

2.8  Analysis  of  Requirements  Consistency  and  Completeness 


The  consistency  and  completeness  of  requirements  has  been  mentioned 
throughout  the  above  discussion.  No  analytical  technique  exists  to 
assure  the  completeness  of  a  set  of  requirements.  The  LARE  approach 
cuts  through  the  target  system  requirements  from  multiple  perspectives 
and  provides  the  analyst  with  a  relatively  small  number  of  items  to 
review.  The  analyst  then  assesses  completeness. 


The  first  type  of  completeness  analysis  is  hierarchical  analysis.  If  a 
system  has  2,000  requirements  defined,  it  is  difficult  to  determine 
whether  the  requirements  are  complete  or  whether  there  should  be  2,001 
requirements.  With  hierarchical  analysis,  each  requirement  is  decom¬ 
posed  into  four  to  seven  components.  At  each  step  of  the  decomposition 
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the  question  is  asked;  Does  the  sum  of  the  sub-requi rements  completely 
describe  the  requirement  at  the  next  level  up?  If  the  answer  is  yes, 
the  decomposition  of  that  requirement  stops;  if  no,  the  missing  require¬ 
ments  are  identified.  This  process  continues  until  the  analyst  feels 
that  the  requirement  has  been  accurately  broken  down.  This  approach 
looks  superficially  similar  to  that  used  in  generating  most  require¬ 
ments  documents.  Specification  fonnats  usually  call  for  a  hierarchical 
paragraph  numbering  scheme.  The  primary  difference  is  that  LARE 
requires  the  strict  logical  relationship  of  parts  between  each  para¬ 
graph  and  its  subparagraphs. 


Next,  data  must  be  analyzed  for  consistency.  At  the  requirements 
stage,  the  basic  objective  is  to  identify  the  type  of  data  needed  and 
derived  by  each  process.  This  identification  procedure  helps  to  ensure 
that  data  is  derived  prior  to  being  required.  It  also  helps  flag  data 
derived  by  multiple  functions.  This  data  should  not  be  described  in 
detail  at  the  requirements  definition  stage.  Defining  the  detailed 
layout  of  internal  data  is  a  problem  for  system  design  and  not  for 
requirements  specification. 


Consistency  analysis  is  predominately  a  problem  of  sorting  through 
multiple  statements  of  individual  functional  requirements.  Con¬ 
sistency  of  requirements  does  not  manifest  itself  until  all  statements 
are  pulled  together.  LARE  aids  the  analyst  in  assembling  the  infor¬ 
mation  and  storing  it  logically.  Inconsistencies  are  not  limited  to 
functional  requirements.  They  can  appear  in  constraints  (e.g.,  per- 
fonnance  requirements),  information  content,  control  flow,  data  units 
(e.g.,  time  to  repair  equipment  in  hours  vs.  days  of  a  person's  time). 
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2 . 9  Loading  of  requirement s  text 


System  specifications  are  frequently  viev/ed  as  a  necessary  evil  which 
must  be  generated  at  the  beginning  of  system  development  only  to  be 
forgotten  once  system  construction  begins.  This  should  not  be  the 
case.  Up-to-date  system  specifications,  are  relevant  throughout  the 
system  life  cycle.  Requirements  generally  undergo  changes  during 
system  development.  To  minimize  system  life  cycle  costs,  analyze  the 
impact  of  requirements  before  developing  system  updates.  Otherwise, 
implementing  new  system  capabilities  or  changes  will  cause  other 
system  errors  or  problems. 


LARE  greatly  enhances  the  ability  to  maintain  up-to-date  system 
specifications.  The  effort  required  to  print  change  pages  or  entire 
specifications  ready  for  publication  is  greatly  reduced.  In  addition, 
LARE  provides  a  single  integrated  database  representation  of  the 
specification.  This  minimizes  divergence  of  functional  and  data 
structures  from  the  requirements  specification  text  representation  - 
likely  occurrence  if  text  is  maintained  manually  or  in  a  separate  word 
processor. 


2.10  Evaluation  of  Several  Existing  Requirements  Anal ysi s 
f'1^  h^d^l^g  i_e  s 


A  cursory  review  was  made  of  tv;o  additional  computer-aided  requirements 
analysis  tools  and  methodologies.  Input/Output  Requi renients  Language 
(lORL),  and  Software  Requirements  Engineering  Methodology  (SREM)  v^ere 
chosen  because  both  are  being  used  by  the  Army  and  are  the  focus  of 
independent  technological  demonstrations  similar  to  this  study.  A 
comparative  evaluation  wa^  made  of  these  technologies  and  LARE. 
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Logicon  developed  LARE  and  greatly  enhanced  the  computerized  tool 
(CADSAT)  used  by  the  methodology.  However,  Logicon  is  committed  to 
the  evolution  of  computer-aided  requirements  analysis  and  specification 
generation  independently  of  the  specific  tools  used.  Tiie  objective  of 
the  evaluation  was  to  identify  the  strengths  and  weaknesses  in  capa¬ 
bilities  of  tools  to  represent  system  documentation.  The  evaluation 
Criteria  are  shown  in  Table  2-1. 
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T  cl  b  1 0 


Ease  of: 


Abi 1 i ty  to; 


Ability  to: 


Ability  to: 


Ability  to; 


2-1.  Evaluation  Criteria 


database  modification 
report  generation 
report  readability 

record/depict  functional  requirements 
record/depict  constraint  requirements 
record/depict  control  flow 
record/depict  data  flow 
record/depict  functional  hierarchies 
record/depict  data  hierarchies 
record/depict  interfaces 
rocord/depict  external  documents 
record/depict  test  requirements 
record /depict  project  status 

aid  in  detection  of  incomplete  data 
aid  in  detection  of  inconsistent  data 
aid  impact  analysis 

generate  system  specifications 
generate  tost  specifications 
generate  design  documentation 

simulate  (general) 
trace  requirements 

trace  between  levels  of  documentation 

provide  diagnostics 

provide  v/ell  defined  mettiodology 
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RESULTS 


3.1  Introduction 


The  results  section  presents  the  findings  in  the  same  order  as  the 
technical  steps  described  in  the  previous  section.  Tables  and  report 
illustrations  are  included  in  this  section.  Longer  example  reports 
have  been  included  in  Appendix  D.  Reports  produced  by  LARE,  except 
the  specification  report,  are  analytical  aids.  These  reports  con¬ 
stitute  a  snapshot  of  the  database. 


3*2  Requirements  Engineering  Plan 


The  Requirements  Engineering  Plan  (see  Appendix  A)  developed  for  this 
project  includes  all  the  basic  elements  used  by  project  personnel.  It 
is  however,  simpler  than  one  for  a  project  which  uses  LARE  as  the 
primary  tool  to  develop  a  complete  system  specification.  A  project 
using  more  people  over  a  longer  interval  would  include  extensive 
discussion  on  requirements  traceability,  use  more  LARE  reports,  and 
discuss  the  tracking  of  requirements  changes/di screpancies  at  length. 


One  key  element  of  the  plan  is  the  identification  of  system  boundaries. 
The  project  was  provided  the  MOM  and  the  MPOM  specifications.  These 
specifications  detail  a  set  of  requirements  for  two  systems,  or 
possibly  two  subsystems,  of  a  much  larger  system,  the  complete  SAMS 
(wholesale,  retail  and  all  levels  of  user/management).  Each  of  the 
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specifications  refer  to  data  processing  functions  (both  manual  and 
computerized),  maintenance  inspections,  actual  maintenance/repair,  and 
maintenance  planning. 


It  was  decided  to  treat  the  MOM  and  MPOM  as  separate  systems  for 
analysis.  Thus,  communication  between  these  two  systems  becomes 
external.  Furthermore,  the  system  boundary  was  defined  to  include 
only  manual  and  automatic  data  processing  functions. 


Manual  data  processing  functions  were  included,  although  they  were  not 
as  well  defined  as  the  automatic  functions,  because  the  line  of 
demarcation  between  manual  and  automatic  processing  functions  might 
change  in  the  future.  Also,  including  manual  functions  enables 
clearer  documentation  of  the  requirements. 


Discussions  of  maintenance,  inspection,  or  maintenance  system  planning 
are  considered  descriptive  (in  terms  of  our  definition  of  system 
boundaries)  and  are  not  addressed  as  functional  requirements.  This 
is  not  to  imply  that  this  material  should  be  removed  from  the  document; 
it  frequently  helps  the  reader  understand  the  actual  functional 
requirements.  Another  implication  of  our  system  boundary  definition  -- 
personnel  operating  the  eventual  system  may  be  part  of  the  system  or  an 
external  interface.  Operators  become  part  of  the  system  whenever  they 
perform  manual  data  processing  functions,  e.g.,  developing  a  list  of 
non-operational  equipment  by  going  through  a  file  containing  equipment 
status  for  each  item.  Physically  locating  each  piece  of  equipment  and 
inspecting  it  to  determine  operational  readiness  is  not  a  data  proces¬ 
sing  function.  The  operator  performing  this  task  is  not  directly 
related  to  the  system  as  defined.  Entering  the  results  of  an  in^;'°r- 
tion  into  a  box  on  an  inspection  sheet,  onto  a  form  for  keypunching,  or 
directly  keying  the  results  into  a  computer  terminal,  all  constitute  the 


22 


"input"  of  data  into  the  "system"  from  an  external  "interface".  In 
this  case,  the  operator  is  the  external  "interface". 


3.3  Functional  Requirements  Identification 


Functional  requirements  for  both  systems  were  broken  down  into  discrete 
requirements.  As  with  all  specifications  for  which  LARE  has  been 
applied,  the  requirements  were  found  to  be  scattered  throughout 
the  documentation.  Most  requirements  were  identified  from  the  text 
portion  of  the  specifications.  Analysis  of  appendices  primarily 
identifies  data  inputs/outputs,  i.e.,  data  from  or  to  external  sources 
or  external  users. 


In  addition  to  functional  requirements,  other  requirements  were 
identified  which  do  not  “do"  something  but  say  something  about  how  or 
when  things  are  done.  These  requirements  are  called  constraints,  and 
were  defined  mainly  in  the  MPOM  database. 


After  identifying  a  functional  requirement  a  descriptive  LARE  name  was 
assigned,  a  synonym  was  defined,  and  a  paragraph  reference  linked  to 
the  analyst  assigned  name.  Figure  3-1  is  an  example  of  how  functional 
requirements  are  extracted  from  paragraphs  in  the  MOM  specification  and 
translated  into  LARE  tenninology.  The  figure  also  shows  how  the  same 
function  is  repeated  in  several  paragraphs.  Figure  3-2  was  generated 
by  prompting  the  database  for  all  names  associated  with  paragraphs 
m-4.10.g,  m-4.10.q,  and  m-4.10.x.5  (MOM).  One  of  L  '  's  greatest 
assets  is  that  it  stores  information  once  but  allows  that  information 
to  be  accessed  in  numerous  ways. 
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3 . 4  Functional  Requirements  Analysis 


The  primary  objective  of  the  functional  requirements  analysis  is  to 
take  the  discrete  functions  identified  in  the  previous  step  and  tie 
them  into  a  consistent,  understandable  functional  hierarchy.  The 
hierarchical  structures  of  both  systems  were  made  as  similiar  as 
possible.  These  structures  include  much  of  the  organization  already 
contained  in  the  specifications. 


Functional  requirements  from  the  MOM  were  loaded  into  a  LARE  com¬ 
puterized  database  first.  Management  information  systems,  including 
maintenance  information  systems,  are  frequently  organized  around  the 
concept  of  input,  processing,  and  output.  The  initial  high  level  MOM 
hierarchy  is  shown  in  Figure  3-3.  This  structure  does  not  lend  itself 
to  an  easy  representation  of  the  lower  functional  structure.  One 
difficulty  is  that  minimal  internal  processing  is  required.  For  the 
most  part,  data  comes  into  the  system,  is  stored,  and  is  reprinted  in 
various  formats. 


A  second  hierarchy,  developed  for  the  MOM  specification,  was  organ¬ 
ized  closely  to  the  original  specification  (see  Figure  3-4  for  the 
top-level  hierarchy).  In  this  structure  the  input,  process,  output 
sequence  repeats  within  each  major  area.  This  structure  handles  the 
lower  level  functions  more  easily  than  the  original.  The  structure 
requires  continued  analysis  in  order  to  meet  the  objective  in  the 
engineering  plan:  each  functional  requirement  to  be  decomposed 
should  yield  4  to  7  subfunctions. 


Once  the  MOM  high  level  hierarchy  had  been  built,  the  MPOM  functional 
requirements  were  organized  into  a  structure  which  retained  as  much 
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Figure  3-3.  Initial  High-Level  MOM  Hierarchy 


Figure  3-4.  Revised  MOM  High-Level  Hierarchy 
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MOM  Structure  and  nomenclature  as  was  consistent  with  the  MPOM  system 
requirements.  Retaining  this  similarity  improves  the  ability  to 
describe  inter-system  communications  (MOM  to  MPOM).  Items  found  in 
the  MOM  but  not  in  the  MPOM  are  included  and  tagged  with  a  "can't 
justify"  memo. 


The  functional  requirements  hierarchy  is  the  "backbone"  of  the  LARE 
computerized  databases  for  both  requirement  sets.  It  provides  a 
concise  view  of  the  system  functions  and  indicates  groups  of  related 
functions.  It  aids  communication  between  users  and  analysts.  If  a 
user's  job  is  to  manually  process  work  orders  and  the  analyst's  job  is 
to  automate  portions  of  the  manual  process,  the  user  must  communicate 
his/her  job  operations  to  the  analysts.  The  analyst,  after  obtaining 
information  about  the  process,  develops  a  structure  that  reflects 
his/her  understanding,  then  uses  that  structure  to  interact  with  the 
user.  A  user  looking  at  the  analyst's  structure  can  readily  see  the 
misunderstandings  or  omissions.  Figure  3-5  is  a  marked  up  structure 
report  that  resulted  from  a  discussion  between  project  personnel. 


The  functional  structure  is  also  useful  for  tying  related  requirements 
togetlier.  The  MOM  and  MPOM  specifications  (like  all  specifications) 
spread  related  requirements  throughout  the  document.  Paging  through  a 
docui;ient  manually  to  establish  relationships  between  items  scattered 
throughout  multiple  chapters  and  documents  is  time  consuming  and  error 
prone.  Maintaining  these  relationships  manually  in  a  dynamic  environ¬ 
ment  is  often  overwhelming. 


The  LARE  functional  hierarchies  of  the  MOM  and  MPOM 
represent  our  understanding  of  the  two  systems  at  a 
structure  also  as:  ^sts  communication  among  analysts 
Further  it  is  the  "skeleton"  on  which  the  system  is 


(see  Appendix  D) 
high  level.  The 
on  the  project, 
built. 
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The  LARE  functional  hierarchy  remains  the  "backbone"  and  concisely 
states  requirements  (baseline)  throughout  the  system  development 
cycle. 


The  following  analyses  are  based  on  the  terminology  developed  in  these 
hierarchies.  An  advantage  of  the  computerized  databases  is  that 
hierarchy  can  be  readily  changed  to  include  results  of  further  analysis. 
The  systems  analyst's  reports  or  working  papers  can  be  reprinted  to 
readily  reflect  any  modifications. 


3 . 5  Control  Requirements  Analysis 


MPOM  control  flows  were  analyzed  and  represented  in  the  LARE  computer¬ 
ized  database.  The  objective  was  to  detennine  the  sequence  of  functions 
in  order  to  show  functional  consistency  and  to  identify  missing  re¬ 
quirements.  In  a  completely  consistent  system  every  functional  re¬ 
quirement  appears  as  a  step  in  at  least  one  control  sequence,  and  every 
control  sequence  has  at  least  one  cause. 


Control  flow  analysis  of  MPOH  proved  difficult  due  to  numerous  missing 
requirements.  These  gaps  left  the  LARE  representation  incomplete. 
Given  more  time  and  access  to  users  to  clarify  requirements,  it 
would  be  possible  to  build  a  complete,  consistent  MPOM  control  flow. 


We  identified  two  major  types  of  missing  requirements:  control 
sequence  activation  and  system  i ni t i at i zat ion.  Many  control  sequences 
can  be  constructed,  but  the  specification  omits  requi reinents  or  fails 
to  state  clearly  iiow  to  start  the  processing.  Potentially,  processing 
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could  be  started  by  particular  messages  being  input,  by  certain  fields 
being  present  in  input  messages,  by  clock  time,  or  by  time  relative  to 
other  processing. 


All  software  needs  procedures  to  load  data  and  start  operation. 
Information  management  systems  like  MPOM  also  need  procedures  either  to 
build  the  initial  database  or  to  start  operations  using  a  database 
built  externally.  The  MPOM  sped f ication  lacks  requirements  addressing 
these  subjects. 


In  some  cases  it  was  not  possible  to  follow  the  control  sequence 
through  the  system  to  an  output.  Conversely  there  were  instances  of 
outputs  not  tracing  back  to  an  input  sequence.  An  example  of  the 
latter  case  appears  in  Annex  H,  Table  406  of  the  MOM.  (See  Figure  3-6) 
Sequence  2  prompts  for  "CRD-DSG."  This  element  is  not  defined  as  an 
input  to  the  Equipment  Recall  process  (See  Figure  3-6) 


3.6  Data  Requirements  Analysis 


MOM  and  MPOM  data  flows  were  analyzed  and  represented  in  LARE  computer¬ 
ized  databases.  All  data  identified  in  the  MPOM  specification  was 
named,  structurally  related  to  other  data  where  appropriate,  and 
tied  to  the  computational  processes.  The  MOM  data  structure  is 
simpler,  concentrating  on  the  nature  of  the  inputs  and  outputs.  Our 
objectives  were  to  identify  redundancy,  inconsistency  and  incomplete¬ 
ness  ’n  the  data  specification.  In  a  completely  consistent  system 
every  input  datum  should  contribute  to  at  least  one  output,  and 
conversely,  every  output  of  the  system  should  be  derivable. 
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Originator:  ^jp 
Verified  by:  kMT 
Sent  to  AIRMrCS: 


DISCREPANCY  REPORT 

I 


Source 


Type  of  Discrepancy 


Remarks 


MOM 


INCONSISTENT  DATA 


ANNEX  H 

DECISION  TABLE 
406 

PG  H-215 
SEQUENCE  2 


SEQUENCE  2  PROMPTS 
FOR  'CRD-DSG'  .  THIS 
ELEMENT  IS  NOT  DEFINED 
AS  AN  INPUT  TO  THE 
EQUIPMENT  RECALL 
PROCESS.  (l2.3d.KY) 
SHOULD  IT  BE 
'CARD-DSG-CD-SAMS' 

(XME  "B")? 


I 


I 

I 

I 


Figure  3-6.  Sample  Discrepancy  Report 
No .  1 
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Inputs  and  outputs  for  both  the  MOM  and  MPOM  are  detailed  in  Annexes. 
After  loading  data  into  the  databases  in  a  specific  sequence,  the 
Name-List  Report  was  used  to  flag  inconsistent  nomenclature.  Figure 
3-7  shows  actual  listing  in  which  inconsistent  nomenclature  between 
input  and  output  elements  surfaced.  Another  example  in  Annex  B  has  an 
output  (03  22  lY)  element  referenced  as  P-WON.  The  corresponding 
input  element  defined  in  Annex  A  (13  11  40)  is  P-WON-ORG.  (See  Figure 
3-8).  This  type  of  inconsistency  makes  it  difficult  to  identify 
instances  of  data  'used'  but  not  "derived".  Although  inconsistent 
naming  functions  are  thought  of  as  clerical  mistakes,  they  create 
nightmarish  debugging  problems  if  an  output  module  expects  P-WON  and 
the  input  module  defines  P-WON-ORG. 


In  attempting  to  tie  internally  defined  data  with  the  data  defined  as 
inputs  and  outputs,  the  discrepancies  multiplied.  Internal  data  are 
defined  by  the  specifications,  especially  in  the  decision  tables.  In 
a  great  many  cases,  the  internal  data  could  not  be  associated  with  the 
inputs  or  outputs  by  name.  For  example.  Annex  H  of  the  MOM  Table 
Number  1368,  sequences  2,  3  and  6  prompt  for  DIC-SUP-ACT,  we  were 
unable  to  locate  an  input  so  defined.  (See  Figure  3-9).  Further¬ 
more,  the  specifications  did  not  identify  specific  processing  steps 
that  would  have  allowed  us  to  link  the  data  or  show  that  multiple 
naming  had  occurred. 


When  the  specifications  identified  data  characteristics  (e.g.  legal 
values)  these  were  recorded  in  the  LARE  databases  as  attributes. 

When  a  piece  of  data  had  attributes  already  entered,  LARE  would  flag 
attempts  to  enter  new  attributes  of  the  same  type.  From  this  the 
analysts  knew  to  check  for  consistency.  Inconsistency  does  not 
automatically  imply  incorrect  data,  it  must  be  checked  by 
analysts.  For  example,  MPOM  input  element  END-ITEM-COMP-IND-FLD 
(Annex  A,  13  01  8W  FLO  3)  is  defined  as  alphanumeric.  The  only 
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Figure  3-7.  Example  Name-List 


Originator;  JAM 
Verified  by:  KJF 
Sent  to  AIRMrCS: 


DISCREPANCY  REPORT 


Source 


Type  of  Discrepancy 


MPOM 


INCONSISTENT  DATA 


03.23. lY 
XMO 

ANNEX  B 
PG  B-59 
I3.n.4D 
XMJ  INPUT 
PG  A-49 


FIELD  #2  IS  OUTPUT  AS  P-WON  BUT  INPUT  AS 
P-WON-ORG. 


Figure  3-8.  Sample  Discrepancy  Report 
No.  2 


Remarks 


ARE  P-WON-REFERENCES 
SYNONYMOUS? 
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Originator:  KMT 
Verified  by: 

Sent  to  AIRMICS: 


DISCREPANCY  REPORT 


Source  Type  of  Oiscreoancv  Remarks 


MOM 


QUESTION 


ANNEX  H 

TABLE  NO.  1368 
PG  H-640 
SEQUENCES  NO. 
2,3,6 


Figure  3-9. Sample  Discrepancy  Report 
No.  3 


WHY  IS  THE  "DIC-SUP-ACT" 
BEING  PROMPTED? 

WE  WERE  UNABLE  TO  LOCATE 
THAT  ELEMENT. 

SHOULD  THIS  BE  "SUPPLY 
SUPPORT  ACTIVITY  NUMBER" 
(SUP-SPT-ACT-NO) 

M-0;510-01? 


I 


LOGICON 


1 

I 

I 


I 

I 

I 

I 

I 

I 

I 

I 

I 


legal  values  are  alphas.  This  is  inconsistent  but  not  necessarily 
illegal  as  far  as  the  system  is  concerned.  (See  Figure  3-10). 

Data  analysis  identified  other  problems  worthy  of  attention.  One  is 
redundancy.  Instances  of  duplication  were  found  where  different 
users  defined  the  same  input  in  several  ways.  Other  data  structures 
which  appeared  dissimilar  on  casual  inspection  were  shown  by  LARE 
reports  (Consist/Compare  Report)  to  consist  of  identical  components. 
(See  Figures  3-11).  Inputs  and  outputs  that  appear  similar  could  be 
identical  if  data  components  with  slightly  different  names  are  in  fact 
identical.  Reducing  redundancy  cuts  storage  and  processing  costs,  and 
increases  target  system  efficiency. 

The  Consists  Comparison  Report  provides  visibility  into  the  impact  of 
certain  changes.  For  instance  changing  the  "part-number-field"  from  a 
numeric  to  an  alpanumeric  would  impact,  at  a  minimum,  the  circled 
items  on  the  matrix  report.  (See  Figures  3-11). 

Another  problem  is  the  specification  of  design  approaches  -  not 
requirements  -  which  imply  inefficient  when  implementation.  For 
example,  the  Supply  Status  File  for  MPOM  is  sorted  on  each  update  and 
sorted  again  for  each  use.  Sorting  is  a  time  consuming  process  which 
should  be  minimized  to  increase  processor  availability.  This  may  be 
accomplished  in  the  example  case  by  carefully  choosing  the  occasion 
for  sorting  and  perhaps  by  trading  off  some  storage  in  which  to  save 
secondary  sort  keys.  Further,  sorting  of  new  updates,  followed  by  a 
merge  with  previous  data  would  reduce  processing  time. 
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Originator;  JAM 
Verified  by:  KJF 
Sent  to  AIRMICS: 


DISCREPANCY  REPORT 


Source 


Type  of  Discrepancy 


MPOM 


INCONSISTENT  DATA 


ANNEX  A  CONFLICTING  FIELD  TYPE  AND  VALUES  FOR 

13.01 .8W.WOR  END-ITEM-COMP-IND-FLD. 

FLD  3 
PG  A-U 


Figure  3-10.  Sample  Discrepancy  Report 
No.  4 


Remarks 


FIELD  TYPE  IS  ALPHA¬ 
NUMERIC,  BUT  THE  ONLY 
LEGAL  VALUES  ARE  ALPHA 
(E  OR  C).  SUGGEST 
FIELD  TYPE  OF  "ALPHA" 
FOR  THIS  FIELD. 


39 


C  f  C  (  (((((((((  i  !((((  ( 


c  c  c  c  c  a  etc  cccccccccccccccc 
ccFec  |e{eipe£eEf?£f££Eec£ee 


u 

4J  • 
A4  t)  O 

•4  C 

C  O  4t  ^ 
a  I  a 

t  W  «4  ft 

4J  41  I  T9 
i«  E  ft«  ft* 
Q  O  41  O 

a  «4  ^  • 
a  M  E  ftr 
a  a  o  u 

«•  O  C  B 
I  ft  ft  ft 

4»  41  C  C 
^  O  O 

o  O  ««  «4 
O  O  -w*  W 

ft  I  «  « 

TJ  TJ  V*  U 


«4  «4  t9  T* 

c  c  .o  o 

9  a  4  E 


'M  ««{  A  ft,  < 

O  C  E  4* 
C  c  a  M  I 
«4  44  C  ft  4 

O  O  «4i^  . 

c  c  ft.  a 

*4  *4  •  O 
*4  a  4;  I 


f  ft  c 

p  a>  4>  E 

C  T9  tJ 

r  *4  c  o 
p  >  a  ft  14 

(  ft*  O  O  4 
'•4CC»- 
»  ft*  I  *4  • 

'  C  £  C 
:  tp  E  a  a* 

P  T9  ft*  O  44 


X 

ft* 

4* 

w 

ft« 

£ 

H 

o 

• 

«9 

o 

• 

>4 

4f 

"a 

• 

«9 

*4 

« 

ft4 

• 

C 

o 

o 

c 

A 

> 

ft* 

•  a 

«4 

ft«  «4 

«• 

X 

ft4 

• 

* 

C 

• 

M 

'  o 

•- 

a 

c  a 

a 

V 

^  i 

1  u  a 

X 

o 

W  o 

4* 

ft4 

u 

C  ft*  1 

ft. 

X 

»  a  ' 

« 

►  ao*4C4*n^*f>vor‘ac>0‘0*4f4m4ft 


ar 

' 

o  « 

44 

c 

44 

44 

4* 

44 

44 

44 

4* 

44 

44 

4*  4* 

44 

44 

4* 

44 

44 

44 

44 

u 

44 

4* 

44 

44 

44  1 

O 

•1 

I 

41  44 

44 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

a 

u 

C 

^  TJ 

c 

0 

a 

o 

a 

a 

Q 

a 

CI 

a 

a 

a 

a 

a 

o 

a 

a 

o 

a 

a 

o 

o 

a 

M 

o 

• 

U  «p 

• 

4 

c 

c 

c 

c 

c 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c  1 

t9 

o 

•ft 

O  £ 

c 

•ft 

•  44 

44 

,4 

44 

'*4 

,4 

•r4 

v4 

,4 

,4 

•*« 

*•4 

••4 

•4 

•4 

•4 

W4 

*•4 

*p4  , 

O 

4* 

4* 

0 

I 

,3 

e 

..4  4P 

£ 

a 

« 

41  ft* 

• 

« 

T9 

0 

«4 

a 

ft* 

^4 

c 

>  C 

ftft 

C 

a 

a 

a  a 

£ 

o 

w4 

0 

•  ^ 

• 

• 

ft 

ft. 

0 

c 

0 

A 

0 

0 

0 

0 

*4 

w4 

£ 

0 

£ 

£ 

E 

£ 

0 

*^ 

o 

ft 

ft 

0 

0 

44 

ft. 

0 

a 

c 

« 

a 

ftft 

K 

K 

Ct 

,4 

£ 

£ 

ft. 

a 

0 

ft* 

a 

a 

44  44 

C 

o 

• 

• 

ft 

0 

44 

0 

0 

0 

0 

0 

a 

0 

..4 

« 

c 

M  44 

• 

a 

TJ 

T9 

T> 

T9 

4» 

> 

0 

44 

44 

ft* 

0 

0 

0 

I 

o 

0 

o  j 

■  «4 

«  B 

a  • 

a 

ft* 

ft* 

ft* 

ft* 

0 

o 

ft. 

0 

«4 

,4 

«* 

a 

44 

a 

4* 

0 

0 

0 

ft* 

44 

^  i 

r<i 

* 

a  44 

'44 

o 

O 

O 

O 

a 

ft 

0 

0 

a 

44 

ft* 

0 

o 

ft* 

a 

>  44 

0 

oc 

,c 

O  * 

O  E 

0 

« 

0 

0 

U 

0 

0  a 

a 

C 

B 

B 

a 

c 

o 

a 

*•* 

M 

44 

0 

c 

a 

*- 

fft 

■  K 

'tp 

w  w 

4*  «-4 

E 

44 

0 

0 

0 

0 

0 

ft. 

0 

0 

0 

0 

0 

0 

ft* 

£ 

0 

o 

•  ! 

• 

v4 

> 

B 

a  o 

0 

C 

ft. 

ft* 

ft* 

ft. 

a.  ft4 

o 

ft. 

r 

C 

ft. 

E 

0 

0 

0 

a 

ft. 

44 

0 

0 

0 

0  1 

ft* 

>«4 

4P  O 

£ 

0 

t 

• 

ft 

A 

,4 

ft 

44 

1 

ft 

44 

ft. 

44 

0 

o 

O 

0 

a 

r 

44  1 

fti 

a 

C  ft* 

•  O 

0 

E 

0 

0 

0 

0 

a 

i£ 

« 

c 

A 

c 

c 

o 

44 

c 

0 

« 

44 

ft*  u 

ft. 

0 

44 

44 

44 

4* 

a 

a 

ft. 

0 

.4 

.4 

a 

0 

E 

0 

V* 

ft. 

0 

a 

c 

c 

41 

4« 

m  c 

0 

ft. 

• 

0 

0 

0 

0 

0 

O 

0 

0 

0 

0 

44 

a  a 

> 

0 

44 

> 

O 

c 

ft 

o 

C 

•  C 

■  w4 

•44  n 

0 

T9 

a 

0 

ft. 

B 

c 

0 

0 

0 

T 

0 

0 

0 

44 

ft. 

ft. 

0 

o 

0 

44 

«4 

«ft 

44 

ft*  ft* 

m 

m 

a 

• 

• 

ft 

0 

0 

0 

0 

0 

a 

ft. 

O 

a 

o 

0 

4. 

0 

o 

m 

« 

c  m 

c. 

a  X 

ftft 

ftc 

ftft 

t 

c 

ft* 

ft. 

ft* 

ft* 

^  a 

c 

o 

a 

4. 

ft. 

„ 

ft. 

C 

«P 

c 

£  *4 

B 

0 

0 

0 

0 

0 

a 

o 

O 

0 

0 

a 

a 

V 

0 

0 

4p 

• 

ft* 

•1  44 

a 

9 

0 

ft. 

O 

O 

O 

o 

>4 

V4 

%t 

0 

44 

44 

44 

•4 

o 

o 

I, 

ft* 

ft* 

ft* 

ft* 

ft. 

o 

0 

> 

ft4 

« 

c 

<*4  C 

0 

1 

44 

44 

M 

W 

«4 

44 

0 

44 

c 

c 

c 

w* 

ft. 

ft* 

o 

0 

0 

0 

0 

0 

£ 

0 

c 

C  T9 

0  O 

O 

s 

o 

0 

0 

0 

0 

0 

0 

0 

ft* 

•* 

0 

0 

0 

•ft* 

a 

o 

» 

4/ 

44 

44 

44 

44 

a 

ft*  . 

o 

M 

a  4) 

l4 

u 

0 

ft* 

ft 

0 

ft* 

ft. 

ft 

0 

m 

£ 

£ 

0 

0 

0 

0 

0 

c 

1 

\» 

^  c 

»<* 

c 

m 

c 

c 

c  c 

0 

0 

A 

m 

C 

a 

O 

O 

44 

44 

44 

E 

c 

E 

E 

E 

£ 

0 

ftO 

O 

O  44 

>• 

1 

0 

0 

0 

o 

*4 

w4 

,4 

m 

0  ^ 

V* 

44 

0 

c 

c 

0 

0 

0 

0 

0 

0 

u 

4*  « 

o 

o 

u 

u  « 

r  c 

c 

» 

44 

c 

c 

c 

c 

•4 

.4 

•4 

o 

V* 

a 

a 

a 

C. 

V* 

,, 

ft* 

ft. 

ft* 

ft. 

ft. 

4* 

4* 

ft* 

4C 

v4 

ft! 

0  44 

0 

0 

44 

0 

0 

0 

0 

0 

0 

0 

ft* 

a 

a 

a 

a 

*4 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

o 

■ft 

• 

•  c 

44 

l4 

0 

A 

A 

A 

0 

0 

0 

0 

0 

0 

0 

0 

«4 

£ 

£ 

a 

Cft 

a 

a 

a 

a 

o- 

a 

'  2  2  2  s ;:  5  s'i 


LV.. 


Figure  3-11.  Example  Consists  Comparison  Report  -  Part  I 


Figure  3-11.  Example  Consists  Comparison  Report  -  Part  II 
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Figure  3-11.  Example  Consists  Comparison  Report  -  Part  III 
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3 . 7  Requirement  Traceabi 1 i ^ 


Prior  to  a  detailed  review  of  MOM  and  MPOM  specifications,  it  was 
thought  that  the  MOM  specification  was  a  more  detailed  discussion  of 
the  MPOM  system.  Close  examination  showed  that  although  many  processing 
functions  are  the  same,  MOM  and  MPOM  support  different  levels  of  Army 
maintenance  management.  These  systems  transfer  information  back  and 
forth  and  must  therefore  be  capable  of  interfacing.  But  requirements 
traceability  as  such  was  not  possible.  It  is  discussed  here  in  the 
abstract  because  it  is  felt  to  be  a  key  issue  in  the  development  and 
maintenance  of  complete/consistent  specifications. 


One  objective  of  this  study  was  to  demonstrate  the  appl icabi 1 ity 
of  LARE  to  Army  system  specifications.  What  follows  is  a  discussion 
of  how  requirements  traceability  is  done.  Several  sample  reports  have 
also  been  included. 


Most  large  systems  have  a  hierarchy  of  documentation  or  specifications. 

Generally,  the  following  types  of  information  can  be  found: 

•  User  notes,  letters,  concept  papers  --  proposals  to  support 
the  initial  systems  engineering 

•  User  requirements  document  --  statement  of  the  system 
requirements  from  the  user  perspective 

•  System  functional  requirements  document  --  the  general 
functional  system  requirements  (GFSR)  in  Anny  nomenclature 
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•  Detailed  functional  requirements  document  --  the  detailed 
fuiKMonal  system  requirements  (DFSR)  in  Army  naaenclature 

t  Sys-^.i  test  requirements  --  the  set  of  requirements  for 
systeia  testing  prior  to  the  government  agency  accepting 
del i very. 

•  System  design  specification  —  detailed  description  of  the 
system  architecture  (hardware  and  software)  which  will  be 
built  to  mf'et  the  system  required  capability 

0  Hardware  layouts  and  prints,  or  software  listings 

Many  problems  of  system  development  and  maintenance  can  be  avoided  by 
clearly  documenting  system  requirements  traceability.  Development  is 
improved  because  all  requirements  end  up  in  hardware  or  software 
implementation  and  all  key  requirements  get  tested  prior  to  system 
acceptance.  Following  the  requirements  from  the  top  level  all  the  way 
down  to  the  hardware  prints  or  software  listings  achieves  traceability. 


System  maintenance  (changes  to  the  system  as  requirements  change) 
can  cost  less.  All  too  frequently,  system  failure  results  when  the 
obvious  changes  are  made  in  software  modules.  Good  requirements 
traceability  documentation  clearly  aids  identification  of  all  necessary 
changes,  not  just  the  obvious  ones.  LAKE  helps  by  listing  closely 
related  requirements,  the  analyst  determines  the  necessary  changes. 
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An  example  ot  a  typical  requirements  traceability  report  is  shown 
in  Fujure  J-1^.  The  report  is  printed  showing  traceability  from  a 
h  iyher- level  to  a  lower-level  specification  (traceability  between  any 
two  separate  databases).  The  report  automatically  prints  the  trace¬ 
ability  from  the  lower  level  to  the  higher  level.  It  also  lists 
requi reiaents  which  exist  in  the  specifications  but  which  are  not  found 
in  the  databases  and  lists  requirements  for  which  there  is  no  trace¬ 
ability  in  either  direction. 


3.0  Consistency  and  Completeness  Analysis 


Inconsistency  or  incompleteness  of  requirements  is  found  by  performing 
the  tasks  described  in  the  preceding  paragraphs.  Rather  than  scatter 
the  discussion  a  separate  subsection  suntiiarizes  and  discusses  the 
problems.  While  this  analysis  identified  numerous  problems,  the 
analysis  has  been  kept  superficial  to  demonstrate  the  applicability  of 
the  technology  rather  than  to  exhaustively  identify  problems. 


Tables  3-1  and  3-2  summarize: 

t  types  of  discrepancies 

•  LAKE  reports  which  aided  discrepancy  identification 

•  tally  of  di screpanci es  formally  written-up 

3.9  Sp^ccification  Generj^jon 


A  sample  of  text  printed  by  LAKE  is  shown  in  Figure  3-13.  The  state¬ 
ments  or  paragrap'lis  of  individual  requirements  are  much  shorter 
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Table  3-1.  Discrepancy  Reports  Breakdown 
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LOGICON _ 

than  in  the  original  specification.  This  is  consistent  with  the 
recommended  LARE  methodology;  each  numbered  paragraph  must  impose 
a  requirement.  Most  paragraphs  in  the  original  specification  contained 
multiple  requirements. 


Additional  elements  of  the  methodology,  not  used  in  this  effort, 
provide  editing  of  the  text  statements,  automatically  record  changes 
in  requirements  and  create  a  history  file  of  previous  requirements 
statements.  The  facility  assists  system  configuration  control  and 
flags  requirements  which  have  changed  since  the  analyst's  last  reading 
of  the  document.  An  example  format  used  by  Logicon  for  the  Air 
Force's  Joint  Surveillance  System  (which  required  this  capability)  is 
shown  in  Figure  3-14. 


3.10  Evaluatio n  of  Alternative  Methodologies 


Three  requirements  analysis  methodologies  were  selected  for  a  cursory 
comparative  evaluation:  LARE,  SREM,  and  lORL.  A  brief  overview 
is  included  to  provide  the  reader  a  context  for  the  comparative  dis¬ 
cussion. 


LARE  is  a  methodology  built  around  Logicon's  extended  CADSAT.  As 
stated  earlier,  LARE  evolved  from  the  University  of  Michigan's  Problem 
Statement  Language  (PSL)/  Problem  Statement  Analyzer  (PSA).  In 
addition,  LARE  includes  the  Functional  System  Simulation  Data  Pro¬ 
cessing  System  (FSDPS)  which  assists  system  feasibility  analysis  and 
performance  estimation.  An  overview  of  the  LARE  computerized  support 
is  shown  in  Figure  3-15. 
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Figure  3-14.  Sample  of  LARE  Generated  Text  ~  Format  II 
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Figure  3-15.  Schematic  Diagram  of  CADSAT-Defined  MIS, 
Structures,  Control  and  Data  Flow 
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SREM  is  a  methodology  built  by  TRW  which  uses  computer  assistance; 
Requirements  Statement  Language  (RSL)  and  the  Requirements  Evaluation 
System  (REVS).  This  tool  also  evolved  from  PSL/PSA.  However,  REVS 
moved  much  more  radically  from  the  standard  PSL/PSA  concepts.  The  only 
thing  that  remains  is  the  Fortran  data  base  management  system  (DBMS)  at 
the  heart  of  REVS.  The  input  processors,  analysis  routines,  and  report 
generators  have  all  been  rewritten  in  Pascal.  An  overview  of  the 
functions  and  capabilities  of  REVS  is  shown  in  Figure  3-16.  The  REVS 
database  containing  the  system  description  (defined  by  RSL  statements) 
is  called  the  Abstract,  similar  to  the  CADSAT  or  PSL  languages  but 
includes  several  enhancements  (especially  for  representing  functional 
flows  -  see  Figure  3-17).  One  of  the  advantages  of  RSL  is  the  ability 
to  define  or  modify  language  constructs. 

REVS  appears  capable  of  producing  whatever  outputs  the  user  desires 
from  any  reasonable  inputs.  The  user  can  perform  either  functional 
or  analytical  simulations.  (This  is  the  only  tool  reviewed  which  has 
an  analytical  simulation  capability.)  The  difficulty  for  the  user  of 
REVS  is  that  every  module  simulated  must  be  described  in  Pascal 
statements  and  the  user  must  write  a  driver  in  Pascal  which  simulates 
the  external  system  environment.  REVS  provides  three  basic  capabil¬ 
ities  to  support  simulation:  an  executive  controller,  a  set  of  simu¬ 
lation  utilities,  and  automatically  generated  Pascal  data  descriptions 
for  variables  used  by  each  module.  The  structure  of  the  REVS  simulator 
is  shown  in  Figure  3-18. 

Input  Output  Requirements  Language  (lORL)  is  supported  by  a  system 
developed  by  Teledyne  Brown  Engineering.  The  language  is  not  pro¬ 
prietary  but  the  computer  system  processing  the  language  is.  The 
language  may  be  described  as  a  graphics  language  for  describing  either 
a  set  of  system  requirements  or  the  actual  system  design.  Functional 
interrelations  are  illustrated  in  Figure  3-19  and  3-20. 
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Figure  3-17.  Sample  R  NET  Structure  in  RSL  and  in  Graphical  Form 


SIMULATION  PROGRAM 


REVS  Simulator  Functional  Components 


1 


<  INTERFACE  DE  S 16  > 
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<  INTERFACE  OESlG> 
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<suasYSTEn  oesign> 

<SUQSYSTEM  NAME ><( SBOSUBSCR > 1 > 
<OESCR IPT ION  > 


(NEW  IMT  0ES1G> 
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Figure  3-20.  Illustration  of  lORL  Schematic 
Block  Diagram 
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Table  3-3  shows  the  individual  ratings  assigned  to  LARE,  SREM  and  lORL 
with  respect  to  the  twenty- four  categories  listed.  Categories  were 
weighted  equally.  The  overall  rating  is  a  simple  average. 


No  distinction  was  made  between  tool  performance  in  the  various 
categories  and  the  degree  of  human  expertise  required  to  achieve 
results. 


While  we  recognize  that  this  is  an  overly  simplified  approach,  a  more 
comprehensive  evaluation  was  not  within  the  scope  of  the  project. 


Recommendations  to  reduce  LARE's  cited  weaknessess  are  discussed  in 
Appendix  C.  All  enhancements  involve  improvements  in  the  presentation 
or  display  of  information. 
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LARE 

SR  EM 

lORL 

gilTE^IA 

RATIfiG 

Ease  of: 

database  modification 

2 

2 

2 

report  generation 

3 

0 

O 

3 

report  readability 

2 

2 

2 

Ability 

to; 

record/depict  functional  requirements 

3 

3 

3 

record/depict  constraint  requirements 

3 

1 

1 

record/depict  control  flow 

2 

3 

3 

record/depict  data  flow 

2 

2 

3 

record/depict  functional  hierarchies 

3 

1 

2 

record/depict  data  hierarchies 

3 

1 

1 

record/depict  interfaces 

3 

3 

2 

record/depict  external  documents 

3 

2 

1 

record/depict  test  requirements 

2 

1 

1 

record/depict  project  status 

3 

1 

1 

Abi 1 i ty 

to; 

aid  in  detection  of  incomplete  data 

3 

2 

1 

aid  in  detection  of  inconsistent  data 

3 

2 

1 

aid  impact  analysis 

3 

2 

2 

Ability 

to; 

generate  system  specifications 

2 

1 

1 

generate  test  specifications 

2 

1 

1 

generate  design  documentation 

2 

2 

2 

Abi 1 i ty 

to; 

simulate  (general) 

2 

1 

0 

trace  requirements 

3 

1 

1 

trace  between  levels  of  documentation 

3 

1 

1 

provide  well-defined  methodology 

3 

3 

1 

provide  diagnostics 

2 

2 

2 

Totals 

62 

43 

37 

Overall  Rating 

2.58 

1.79 

1.54 

Table  3-3.  Evaluation  Results 
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Cj:^ c  1  u s i 0 ns  and  Recomnie nd a t i  o n s 

Co ncl usions _S p e c if  1c  t his  study 

•  This  test  program  demonstrated  that  LARE  can  be  applied  to 
AIRMICS  requirements.  No  technical  barriers  emerged,  but 
some  operational  guidelines  appear  desirable.  (These 
suggestions  appear  in  the  recommendations.) 

t  LARE's  analytical  effectivess  came  through  clearly  on  this 
project.  Over  250  discrepancies  were  found  in  the  speci¬ 
fications.  They  were  found  by  several  people  in  a  short 
period  of  time  (6  months)  who  had  no  familiarity  with  Army 
specifications  or  with  maintenance  systems.  In  addition, 
there  was  no  contact  with  the  system  users  although  some 
clarifications  were  requested  from  AIRMICS.  The  problems 
identified  are  presumably  a  small  sample  of  those  existing. 
Problem  identification  was  only  one  objective.  Much  more 
of  the  effort  was  spent  documenting  the  methodology  and 
illustrating  how  the  methodology  can  be  applied. 

•  Review  of  alternative  tools  identified  three  key  performance 
differences ; 

•  LARE  provides  the  best  overall  requirements  engineering 
support . 

•  SREM  offers  the  best  functional  flow  presentation 
but  focuses  on  describing  system  design  rather  than 
requi rements. 
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•  lORL  displays  the  best  graphics  representation  of 
requi  reinents . 

The  cursory  review  permitted  in  a  short  time  limits  the  conclusions  to 
these  first  impressions.  Comparison  was  further  hampered  by  insufficient 
internal  documentation  and  inadequate  experience  in  applying  these 
other  tools. 


4.2  Conclusions  Supported  by  this  Study  and  Prior  Experience 


4.2.1  Basis  of  the  Conclusions.  General  conclusions  are  based  on 
the  results  of  this  study  and  Logicon's  experience  over  the  past  six 
years  with  computer  aided  requirements  engineering  and  development  of 
software  tools  to  support  analysis.  Some  LARE  capabilities  could  not 
be  demonstrated  by  this  project,  including:  configuration  control 
assistance,  feedback  to  analysts,  defining  the  system,  and  assistance  in 
analyzing  impacts  of  requirements  changes. 


Since  LARE  was  shown  to  be  effective  and  applicable  to  AIRMICS,  Logicon's 
prior  experience  suggests  that  LARE  could  also  effectively  handle 
communications  and  weapons  systems. 


4.2.2  Assistance  to  Configuration  Control.  Configuration  control 
of  system  requirements  includes  many  things.  One  element  is  control  of 
the  statement  of  requirements  and  the  republication  of  documentation. 
LARE  assists  this  process.  LARE  enables  changes  in  requi renients  to  be 
flagged  as  either  insignificant  (correction  of  typos)  or  significant 
(change  of  the  actual  requirement  or  constraint).  In  addition,  the 
technology  provides  an  ability  to  move  obsolete  requirements  to  history 
files  and  to  retrieve  these  requirements  for  analysis.  If  a  particular 
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area  of  requirements  changes  too  frequently,  a  more  general  analysis 
and  change  is  probably  wa'^i'anted.  Demonstration  of  this  capability 
would  have  required  a  longer  time  period  with  an  iterative  interface 
with  the  user. 

4.2.3  Feedback  to  Analysts.  The  general  experience  of  human  and 
computerized  communications  is  that  people  think  communication  is  taking 
place  when  it  is  not.  A  technique  used  to  improve  this  situation  is  to 
provide  feedback  to  the  speaker  or  sender.  In  the  case  of  human 
commun’ cat  ions,  it  is  not  sufficient  for  the  analyst  to  write  a  textual 
document  of  the  requirements  and  ask  the  user  to  answer  yes  or  no  as  to 
whether  it  accurately  represents  user  requirements.  Several  approaches 
exist  for  improving  this  communication  prior  to  the  discovery  that  a 
system  has  been  developed  that  fails  to  meet  major  "requirements". 

One  technique  currently  being  explored  by  AIRMICS  is  "system  sketching" 
which  builds  rudimentary  system  capability  to  enable  the  user  to  operate 
on  samples  of  real  data  to  verify  the  desired  capability.  The  viability 
of  this  approach  depends  on  the  ability  to  develop  "quick  and  dirty" 
solutions  considerably  cheaper  than  the  final  production  system.  A 
second  approach  involves  the  use  of  LARF.  The  requirements  are  ex¬ 
panded  in  levels  and  the  implied  control  and  data  relationships  are 
explicitly  identified  so  that  the  user  can  see  more  clearly  how  the 
analyst  is  interpretating  the  user's  statement  of  requirements 
(verbal  or  written). 

4.2.4  Simulation  of  Systems.  System  simulation  is  frequently 
necessary  to  show  the  feasibility  of  system  development  and  to  bound 
both  costs  and  technology  risks.  A  recent  Logicon  study  (Integration 
of  CADSAT  (i-ARE)  with  General  Purpose  System  Functional  Simulation 
Technology,  Contract  F04701-77-C-0069)  illustrated  LARE ' s  capabilities 
in  this  field  (referred  to  as  the  Functional  System  Simulation  Data 
Processing  System  (FSDPS)).  It  is  a  completely  generalized  simulator. 
Current  internal  Logicon  efforts  include  research  into  driving  this 
simulator  directly  from  a  LARE  dataoase. 
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4.L’.5  F  ii:ie  of  Appl  icaticn.  This  demonstration  applied  LAP.t  to  an 
existing  set  of  requirements  specifications.  While  it  was  said  earlier 
that  the  application  was  successful,  the  results  could  have  been  even 
liiore  beneficial  had  LAKE  been  used  from  the  beginninq  of  ttie  effort 
(during  the  devel opiiient  of  the  first  drafts  of  the  requirements  speci¬ 
fications,  including  ttie  General  Functional  System  Requirements  docu¬ 
ments).  While  it  is  advantageous  to  apply  LARE  as  early  as  possible, 
the  reader  should  not  conclude  tliat  there  is  ever  a  time  for  which  the 
application  is  too  late.  Logicon  has  had  application  experience  on 
other  projects  in  which  the  systems  had  already  been  built  and  imple¬ 
mented  prior  to  using  LARE.  In  terms  of  the  system  life  cycle,  the 
majority  of  the  system  life  is  during  the  operations  and  maintenance 
phase.  During  this  phase,  considerable  effort  is  expanded  handling 
proposed  requirements  changes  and  attempting  to  determine  the  technical 
ramifications  of  these  changes  (what  other  requirements  must  change  and 
how  do  these  i;:ipact  the  implemented  design). 


4.2.6  Initial  Planning  of  LARE  Application.  Another  consideration 
is  time.  A  laonth  or  two  is  needed  for  a  single/couple  of  andlyst(s)  to 
sort  through  the  requirements  and  develop  a  reasonable  draft  to  the 
Requirements  Engineering  Plan.  Analysts  applied  too  soon  in  an  uncon¬ 
trolled  liianner  contribute  to  poor  results  and  a  waste  of  time  and 
money. 


4.2.7  Tiiae  Required  for  Application.  The  effort  should  be  more 
than  six  months  of  calendar  time.  The  requirements  definition  phase 
generally  takes  place  over  a  year  or  two  and  in  some  cases,  several 
years.  Tfie  issue  is  not  one  of  putting  enougli  people  on  the  project 
but  of  having  enough  time  for  the  analysts  to  think  through  the  struc¬ 
tural  rel ati onsiii ps  of  the  requirements  and  get  the  appropriate  reviews 
and  feedback  with  the  system  user  community. 
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4.2.8  J ijiie  ]|[eeded  to  Reorgan i^ze  Database.  Periodically,  the 
requirements  database  needs  to  be  reorganized.  In  the  case  of  a 
requirements  definition  effort,  the  requirements  expanding  or  the 
analysts'  understanding  of  the  requirements  changing  results  in  a  need 
to  modify  the  database.  In  the  case  of  the  analysis  of  existing 
specification,  it  becomes  apparent  that  the  functional  breakout  of  the 
requirements  is  awkward  and  obscures  relationships  to  the  analyst  and 
especially  to  the  user.  Time  is  needed  for  this  reorganization.  The 
ability  to  do  this  in  a  reasonably  short  period  is  one  of  the  major 
advantages  of  having  a  computerized  requirements  specification.  It 
should  not  be  viewed  by  the  analyst  or  management  as  a  poor  or  in¬ 
adequate  job.  The  poor  job  is  the  failure  to  put  effort  into  the 
reorganization  when  the  methodology  indicates  it.  The  need  for  doing 
this  type  of  iterative  restructuring  emphasizes  the  earlier  point  of 
having  more  than  six  months  for  requirements  engineering. 

4.2.9  Updating  Capabilities.  Many  benefits  of  LARE  were  not 
realized  or  illustrated  by  this  study  because  of  the  limited  time 
period  and  scope.  Much  of  the  major  effort  of  requirements  engineering 
involves  analysis  of  the  problem  and  the  loading  of  the  initial 
databases.  Once  loaded,  they  provide  an  inexpensive  and  powerful 
capbility  to  attack  problems  during  both  the  system  development  or 
operations/maintenance  phases  of  the  system  life  cycle.  Also,  as 
additional  use  is  made  of  the  databases,  the  analyst  discovers  require¬ 
ment  relationships  not  previously  perceived.  These  new  relationships 
are  frequently  the  realization  of  the  interdependency  (if  one  require¬ 
ment  changes,  the  other  is  likely  to  change)  between  requirements 
rather  than  identification  of  new  requirements.  As  these  new  relation¬ 
ships  are  discovered,  they  should  be  loaded  into  the  database.  Thus, 
the  LARE  database  provides  a  "corporate  memory"  of  all  analytical 
experience  with  a  particular  system.  This  is  especially  advantageous 
to  deal  with  system  personnel  changes.  A  set  of  manual  notebooks 
maintained  by  individual  analysts  could  not  be  integrated  nor  expressed 
in  as  uniform  a  fashion. 
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4.2.10  Analysis  of  Proposed  Requirements  Changes.  Proposed  require¬ 
ments  change  impact  analysis  is  a  major  area,  often  overlooked. 

People  Logicon  have  spoken  to  have  made  the  assumption  that  sufficient 
effort  was  going  to  be  applied  up  front  in  order  to  eliminate  the  need 
for  significant  changes  to  the  system.  Our  experience  is  that  it  is 
very  unusual  for  the  system  to  be  implemented  prior  to  major  require¬ 
ments  changes.  Two  basic  LARE  capabilities  lend  themselves  to  this 
type  of  analysis:  recording  the  interrequirements  relationships 
within  the  computerized  databases  and  reporting  requirements  trace- 
ability  tracing  the  requirements  from  the  top  level  requirements  down 
to  the  individual  hardware  components,  software  modules,  or  personnel 
procedures. 

4 . 3  Recommendations 

«  Improve  LARE  by  incorporating  the  R  Net  capability  of  SREM 
and  augmenting  the  existing  graphics  capability  with  the 
use  of  lORL. 

•  Augment  LARE's  specification  generation,  data  representa¬ 
tion/display  and  information  reporting  capabilities  in  the 
areas  detailed  in  Annex  C. 

t  Apply  the  enhanced  LARE  to  specify  an  Anny  system  from 
initial  requirements  through  implementation,  using  the 
following  guidelines: 

1.  Adequate  time  for  initial  requirements  definition 

2.  Develop  a  realistic  Requirements  Engineering  Plan 

3.  Require  adequate  "feedback"  sessions  between  users 
and  analysts 


4.  Allow  time  for  reorganization  of  databases  with 
respect  to  incorporating  change 

b.  Simulate  the  proposed  system 
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APPENDIX  A 

REQUIREMENTS  ENGINEERING  METHODOLOGY 


A.  INTRODUCTION 


This  Appendix  details  the  requirements  engineering  plan  used  to  analyze 
two  Army  Detailed  Functional  Specification  Requirements  (DFSR)  speci¬ 
fications. 


Each  project  must  make  decisions  about  which  of  the  numerous  LARE 
language  features  will  best  suit  their  individual  needs.  The  main 
consideration  in  developing  the  AIRMICS  specific  plan  was  the  deter¬ 
mination  of  which  LARE  reports  would  best  represent  the  information  in 
the  MOM  and  MPOM;  and  which  reports  would  be  used  by  analysts  to  detect 
problems.  All  of  these  decisions  must  be  based  on  the  goals  and 
objectives  of  the  project. 


A.l  LARE  Language  Features.  The  specific  language  features  chosen  for 
this  project  are  di scus'sed"  at  length  in  Appendix  B.  LARE  is  a  language 
for  describing  system  requirements  and  design.  It  is  not  a  procedural 
programming  language.  It  provides  a  capability  for  naming  objects  and 
providing  textual  descriptions  of  objects  which  play  a  role  in  the 
system.  More  importantly,  it  has  the  capability  to  define  relation¬ 
ships  among  the  objects  and  store/generate  text  associated  with  these 
objects. 


Object  names  used  in  this  application  were:  PROCESS,  MEMO,  INTERFACE, 
ATTRIBUTE,  SOURCE,  INPUT,  OUTPUT,  SET,  GROUP,  ENTITY,  and  ELEMENT.  The 
main  relationships  used  to  describe  the  various  aspects  of  the  MOM  and 
MPOM  specifications  were:  RECEIVES,  GENERATES  (data  across  system 
boundaries),  PART  OF  (system  structure)  CONTAINED  IN,  CONSISTS  OF  (data 
definition). 


SYNONYMS,  SOURCES,  ATTRIBUTES  and  DESCRIPTIONS  were  used  to  reflect 
user-defined  values  and  properties.  Emphasis  was  placed  on  establishing 
a  high  level  functional  description  of  the  system  as  well  as  the  contents 
of  the  inputs  and  outputs  used  by  the  system. 


A. 2  LARE  Report  Features.  There  are  three  categories  of  reports/programs : 
application,  update  and  utility.  The  application  reports  aiding  Logicon 
analysts  throughout  this  project  are  discussed  briefly  below  and  in 
detail  in  Appendix  B.  The  update  and  utility  reports  are  discussed  only 
in  this  appendix. 
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A. 2.1  Application  Reports.  The  following  reports  were  chosen  to 
aid  analysts  in  building  the  MOM  and  MPOM  data  bases: 


DB  Status  (DBS) 

Formatted  Problem  Statement  (FPS) 
Structure  Report  (STR) 

Contents  Report  (CONT) 

Name  Generation  (NG) 

Name  List  (NL) 


A. 2. 2  Database  Update  Programs/Reports.  These  programs  enable  the  user 
to  update  the”  databases.  The"  update  programs  commonly  used  on  LARE-aided 
projects  are: 

•  DELETE-PSL  (DPSL) 

Deletes  specific  LARE  relationships  previously  established 
in  the  database.  A  permanent  record  of  the  change  is 
generated  in  the  form  of  the  deleted  -  LARE  Report. 


•  INPUT-PSL  (IP) 

Adds  information  to  records  in  the  database.  A  permanent 
record  of  the  change  can  be  generated  in  the  form  of 
the  AS-IS  Source  Listing  and  Cross  Reference. 


•  RENAME  (REN) 

Changes  a  name  or  list  of  names  in  the  database.  The  Rename 
Report  establishes  a  permanent  record  of  the  change. 


•  DELETE  (DEL) 

Deletes  a  name  or  a  list  of  names  from  the  database.  When 
a  name  is  deleted  all  of  its  connections  to  other  names  are 
deleted  as  well.  A  permanent  record  of  the  change  is  also 
generated  in  the  form  of  the  Deletion  Report. 


•  punch-comment-entry  (PCOM) 

Produces  a  punch  file  u^d  as  an  input  file  to  RCOM  and 
DCOM.  It  is  used  for  changing  and  deleting  textual  database 
entries. 


•  REPLACE_-C0MME_NT-E_NTR2  (RC0_M[ 

lTe"pT¥ces,  Tor  a  gfven  "name,  specific  comment  entries  associated 
with  the  name.  The  Replaced  Comment  Entries  Report  records  the 
chdnge( s) . 


69 


•  delete-comment-entry  (DCOM) 

Deletes,  for  a  given  name  In  the  database,  the  specified 
textual  entry  associated  with  the  name.  The  Deleted 
Comment  Entries  Report  records  the  change (s). 


A. 2. 3  Util ity  Programs.  These  programs  are  used  by  LARE  software 
maintenance  personnel  to  backup,  maintain  databases  (errors  are  oc¬ 
casionally  experienced  by  system  crashes  or  sudden  communications 
termi nations. 

•  DB  DUMP 

Dumps  the  contents  of  a  database  to  the  users'  terminal 
showing  pertinent  information  required  for  debugging 
any  database  problems.  It  provides  a  fonnatted  dump  of 
the  internal  database  structue. 


•  DUMP 

Dumps  a  database,  in  a  sequential  file  format  for  input 
to  RESTORE. 


•  RESTORE 

To  restore  a  previously  dumped  database.  A  database  must 
be  initialized  before  it  can  be  restored. 


• 

Used  to  back  up  databases  from  disk  to  tape. 


f  ^ 

Used  to  restore  databases  from  tape  to  disk  (previously 
backed  by  BCK). 

A. 3  Requirements  Engineering  Procedures.  This  section  addresses  why 
speciTic  choices  were  made.  Analysis,  by  definition,  is  an  iterative 
process.  Time  constraints  precluded  multiple  iterations.  Decisions  on 
how  to  best  represent  the  data  were  made  at  the  onset  of  the  project. 

It  was  decided,  for  instance  not  to  address  the  decision  tables  im¬ 
mediately.  When  they  were  addressed,  it  became  apparent  that  the  sheer 
volume  and  level  of  detail  contained  in  them  could  be  translated  into 
LARE  terms  by  example  only.  This  is  not  to  suggest  that  LARE  cannot 
handle  massive  decision  tables  but  that  considerably  more  time  would 
have  been  needed  to  make  the  conversion. 
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We  decided  to  first  concentrate  on  establishing  a  functional  hierarchy 
of  requirements  for  both  the  MOM  and  MPOM.  This  approach  helps  analysts 
working  with  an  unfamiliar  system  towards  an  understanding  of  what  the 
system  is  supposed  to  do.  In  addition,  the  functions  provide  the  basic 
blocks  or  items,  the  objects  for  which  the  analyst  must  determine  the 
interrelationships. 


After  agreeing  on  a  structure  suitable  to  both  the  MOM  and  MPOM,  we 
diverged  our  emphasis.  The  MOM  database  was  built  to  reflect  inputs 
and  outputs  and  the  detailed  elements  contained  in  each.  The  emphasis 
was  on  Annexes  A,  B,  and  C  of  the  MOM.  We  also  loaded  short  textual 
statements  that  described  the  requirements  as  we  determined  them. 


The  MPOM  database  was  taken  several  steps  further.  We  established 
relationships  in  order  to  illustrate  how  LARE  depicts  control  and 
data  flows.  This  was  in  addition  to  information  described  with  respect 
to  the  MOM  database. 


The  Requirements  Engineering  Plan  is  dynamic  in  nature.  As  unique  problems, 
specific  to  a  project  arise,  they  are  evaluated  and  decisions  about  how 
to  handle  them  are  made.  The  plan  must  be  updated  accordingly  to  be  an 
effective  tool  for  the  analysts. 


Section  A. 4  is  the  plan  given  to  project  team  members  at  the  beginning 
of  this  study.  It  assumed,  at  a  minimum,  an  existing  understanding  of 


LARE. 


A. 4  Procedures  to  be  Followed  on  the  Airmics  Study  Initial  work  on  the 
Army  speciTications  wiTl  concentrate  on: . 

Reviewing  Source  Documentation 

Identifying  System  Functions 

Organizing  Functions  into  a  Hierarchical  Structure 

A. 4.1  Reviewing  Source  Documentation.  Two  requirements  databases 
wi I i  be  initiated  and  developed,  one  for  each  specification.  Read  the 
main  sections  of  the  source  documentation.  Make  notes  about  your 
concerns  and  questions.  If  further  reading  or  referencing  various 
annexes  does  not  address  your  problem(s),  then  write  up  a  Discrepancy 
Report  detailing  the  problem  and/or  question. 
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Highlight  what  you  consider  to  be  system  functions  and  otlier  pertinent  system 
i nformati on. 


A. 4. 2  Identifying  Functional  Requirements  Use  PROCESS  (PRC)  to  identify 
system  functions  in  both  the  MOM  and  MPOM.  The  following  procedures 
are  to  be  conformed  to  when  deriving  the  name  of  a  function: 

•  no  more  than  30  alphanumeric  characters  in  a  name 

•  no  abbreviations  unless  it  is  to  stay  under  30  characters 

•  no  special  characters  in  lead  field  of  name 

t  no  embedded  blanks  (separate  the  words  in  names  with 
hyphens) 

•  whenever  possible,  start  the  name  of  a  functional 

requirement  with  an  action  verb 


The  object  is  to  concisely  name  the  abstracted  function.  Examples 
of  action  verbs  used  in  the  past  are: 


annotate 

i nspect 

enter 

record 

generate 

submit 

determi ne 


forward 

transfer 

sort 

distribute 
retri eve 
not i fy 


Whenever  possible,  avoid  using  LARE-reserved  words  as  the  first  word  in 
an  analyst-assigned  name. 


Use  SOURCE  (SRC)  to  identify  where  in  the  MOM  or  MPOM  specifications  you 
are  extracting  your  information.  If  tiie  information  comes  from  the  MOM, 
use  the  prefix  m-  and  the  appropriate  paragraph  number.  For  source 
paragraphs  from  the  MPOM,  use  the  prefix  p-.  If  annexes  are  F  'j 
referenced,  use  the  appropriate  lead  prefix  followed  by  th"  a:  letter 

For  example: 


m-a-i2.U3.4D 

p-p-03.(}4.«W 


The  first  example  indicates  that  the  information  was  found  in  the  MOM, 
Annex  A.  The  second  example  indicates  the  reference  is  in  the  MPOM, 
Annex  B.  Paragraph  references  rather  than  page  numbers  were  chosen 
for  the  source  references  because  they  arc  less  apt  to  change  during 
any  later  expansions  of  requirements  and  provide  more  accurate  ref¬ 
erences  to  the  specific  requirements. 
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A . 4 . 3  Organizing-Functions  I n t o  a  H i era rch i c a I  S t ru c t u re  As  you  are 
defining  functions,  logical  groupings  will  begin  to  surface.  Use  the 
part  of  (PART)  convention  to  identify  PART/SUBPART  relationships. 
Remember; 


•  a  hierarchy  of  functions  should  provide  a  concise 

overview  of  what  the  system  does  (is  to  do) 

t  a  hierarchy  of  functions  is  independent  of  system 
flow 

t  a  hierarchy,  in  order  to  make  sense,  may  have  to  include 
high-level  collectors  not  specifically  addressed  in  the 
user  documentation  (collectors  are  analyst  invented 
names  for  groupings  of  required  functions.  Collectors 
aid  organization  of  requirements) 

•  a  hierarchy  should  contain  no  more  than  4  to  7  discrete 

requirements  under  any  given  aggregate  function 


A. 4. 4  Analyze  Control  TRIGGERS  (TRGS)/TRIGGERED 

BY  (TRGD)~1  anguage"  feature  to  establish  the  flow  of  control. 

TRIGGERS  should  be  used  to  specify  processing  functions  that  necessarily 
follow  one  another. 


Do  not  use  the  UTILIZES/UTILIZED  By  feature.  Time  and  volume  preclude 
accurately  defining  primary  and  secondary  functions.  Remember  constraint 

•  Primary  function  -  a  function  which  is  part 

of  the  major  mission,  objective,  or  goal  of  the 
system,  e.g.,  provide  listing  of  all  available 
equipment . 

•  Secondary  functions  -  a  function  which  by  itself  is 

not  part  of  the  mission  of  the  system,  e.g.,  provide 
building  space  to  house  personnel  and  equipment  required 
for  the  maintenance  of  a  data  processing  system. 

A. 4. 5  A^nalyze  Da^ta  Req^ui rements.  The  input  and  output  requirements  of 
both  the  MOM  and  MPOM  are  detailed  in  Annexes  A  and  B.  Use  the 
INPUT  (INP)/OUTPUT  (OUT)  constructs  to  identify  inputs  and  outputs. 
Whenever  possible,  use  the  names  already  assigned.  Define  the  inputs 
■■nd  outputs  in  terms  of  the  ELEMENTS  that  they  contain. 
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Use  the  SET  construct  to  collect  inputs  and  outputs  with  multiple  parts. 


Load  INPUTS  and  OUTPUTS  identified  in  the  text  before  loading  the  annexes. 
This  will  facilitate  locating  requirements  called  out  in  the  text  but  not 
detailed  in  the  input/output  sections  and  vice  versa.  It  will  also  help 
point  to  inconsistent  naming  conventions. 


Employ  the  USES/USEO  BY  construct  to  indicate  how  data  is  used  within 
tlie  system.  RECEIVES/GENERATES  should  be  used  to  indicate  how  the  data 
enters  the  system  and  who/what  receives  the  OUTPUTS.  Define  the  who/what 
by  the  INTERFACE  construct. 


A. 4. 6  Analyze  Requirements  for  Consistency  and  Completeness.  This  should 
be  done  at  each  step  of  the  project.  System  completeness  will  be  virtually 
impossible  to  determine.  Concentrate  on  consistency  checks.  Use  the 
Discrepancy  Reports  to  detail  instances  of  inconsistencies  and  information 
that  you  determine  to  be  incomplete. 


A. 4. 7  Load  Text.  This  will  be  done  after  the  hierarchy  has  been  built. 
Generate  a  structure  report  with  assigned  references.  Build  a  file  using 
the  DESCRIPTION  (OESC)  construct.  Use  the  specification  text  that  best 
describes  the  requirement.  If  multiple  requirements  exist  in  one  para¬ 
graph,  extract  text  which  suitably  and  independently  describes  each 
function  you  have  named.  Do  not  load  the  entire  paragraph  every  time  it 
is  addressed. 


A. 4. 8  Use  of  the  Computer  Center.  These  procedures  are  to  be  followed 
by  AIRMICS  project  personnel: 

1)  Each  analyst  is  responsible  for  building  his/her  own  input 

files.  All  input  file  names  are  to  end  in  ".INP". 

2)  Proof  your  own  files  and  submit  to  a  second  party  for 

proofing  before  database  updates  are  requested. 

3)  Databases  are  to  be  updated  by  the  Project  Manager  only. 

If  specific  sequencing  is  required  for  inputs,  specify 
a  numeric  order  in  the  name,  (i.e.,  xxxl.INP,  xxx2.INP) 
Once  a  series  of  files  is  ready  for  loading,  leave  mail 
in  the  PH's  directory  indicating  such. 

4)  Request  report  updates  before  running  them.  This  will 

ensure  that  we  stay  within  budget. 
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5)  Databases  will  be  backed  up  daily,  so  there  is  no  need 

to  clutter  directories  with  unnecessary  files.  On-1 i ne 
storage  is  expensive! 

Your  AIRMICS'  directories  are  to  be  used  for  project-related 
work  only. 
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APPENDIX  B 

A  DESCRIPTION  OF  THE  LARE/CADSAT  APPLICATION  TO  AIRMICS 


B.  ^RODUQION,  This  appendix  describes  how  Logicon  has  chosen  to 
apply  LARE  to  two  Army  DFSRs.  Certain  LARE  terms  (such  as  PROCESS, 
MEMO,  TRIGGERS,  etc.)  which  take  on  specialized  meanings  in  this 
application,  are  discussed.  More  detailed  information  about  LARE  can 
be  found  in  the  documentation  supplied  by  the  University  of  Michigan 
(URL  User's  Manual,  and  URA  User's  Manual,  Report  No.  ESD-TR-78-1 27 , 
Volumes  I  and  II). 


B.l  Definition  of  LARE  Terms 


LARE  terms  used  in  this  application  are  defined  and  explained  in  this 
section.  Where  abbreviations  for  terms  are  accepted  by  the  LARE 
Programs,  these  abbreviations  appear  in  parentheses  following  the 
names  of  the  terms.  A  single  sheet  summary  of  the  definitions  and 
explanations  is  given  in  Table  B-1,  to  assist  the  reader  in  recalling 
this  information. 


B.1.1  L^RE  Jerpii  LARE  names  contain  up  to  30  characters  with  no 
embedded  blanks*,  they  represent  objects  in  the  CADSAT  data  base,  such 
as  PROCESSES,  MEMOS  or  data  aggregates.  In  this  application,  a  name 
is  commonly  made  up  of  several  English  words  or  abbreviations, 
separated  by  hyphens,  to  suggest  the  meaning  of  the  object  it 
represents. 


B.l. 2  PROC‘^S_S__(PRC) .  A  requirement  is  named  as  a  process  if  it  is  a 
functional  requirement,  that  is  if  it  denotes  an  action  which  must  be 
taken.  Thus,  for  example,  "process-work-orders"  is  named  as  a  PROCESS. 


PROCESSES  are  also  used  to  "collect"  non  functional  information 
represented  in  a  specification.  For  example,  chapters  1,  2,  and  3  of 
the  MOM  and  MPOM  contain  information  about  assumptions,  benefits  to  be 
achieved,  statutory  and  other  regulatory  requirements,  etc.  Paragraph 
reference  numbers  (sources)  containing  this  type  of  information  have 
been  attached  to  "collectors".  Examples  of  non-functional  collectors 
are:  header-only,  non-funct i onal -requi rements ,  gfsr-assumpti ons , 
specif ic-dfsr-assumf)tions  and  safeguard-personal-data. 


B.l. 3  MEMO.  A  requirement  is  named  as  a  memo  if  it  can  be  stated  as  a 
constraint  (such  as  sizing  or  timing).  Whenever  appropriate,  a  single 
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CADSAT  Names: 

PROCESS; 

MEMO ; 

SYNONYMS; 

SOURCES: 

DESCRIPTIONS: 

TRACE  KEYS: 

ATTRIBUTES; 

PART,  SUBPART 

APPLIES,  SEE 
MEMO; 

TRIGGERS, 
TRIGGERED  BY: 

UTILIZES, 
UTILIZED  BY; 

CONSISTS  OF, 
CONTAINED  BY 

USE  ;,  USED  BY 

DER,VES, 
DERIVED  BY: 

UPDATES, 
UPDATED  by; 
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Table  B-1.  Summary  of  LARE  Definitions 

Character  strings  up  to  30  characters  in  length,  English 
words  or  abbreviations  from  Table  A-2  suggesting  meaning, 
separated  by  hyphens 

Object  naming  a  functional  requirement  -  e.g.,  an  action 
which  must  be  taken 

Object  placing  a  constraint  on  a  PROCESS  or  providing  a 
description.  MEMOS  always  apply  to  PROCESSES  and  must  be 
so  indicated  on  INPUT 

Given  to  all  PROCESS,  MEMO,  INPUT,  OUTPUT,  ELEMENT 

Given  to  all  MEMOS  and  PROCESSES  Use  alphabetic  prefix 
for  specification,  numeric  paragraph  number  separated  by 
periods,  multiple  sources  allowed. 

Contains  information  relating  to  LARE  object  document 
text  or  description  of  contents  of  data  items. 

Placed  in  higher  level  specification  database  to  provide 
traceability  to  a  lower  level  specification;  same  format 
as  SOURCES. 

Three  types  used  -  frequency,  file  length,  file  type,  LODE 
(Annex  C  ref)  media,  location  and  status 

Places  orocesses. 


Associates  MEMO  with  PROCESS. 


Defines  executive  flow  of  PROCESSES. 

Defines  use  of  other  PROCESSES  as  subroutines. 

Defines  data  structural  relationships. 

PROCESS  uses  data  if  it  operates  on  it  but  does  not  change 
it. 

Applies  to  data  aggregates  generated  by  a  PROCESS. 

Applies  to  data  that  is  changed. 
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memo  may  be  applied  to  more  than  one  process.  Memos  are  also  used  to 
call  attention  to  special  cases  and  are  helpful  as  a  way  of  communi¬ 
cating  between  analysts.  For  example,  a  memo  tag  attached  to  a  series 
of  output  requirements  stating  "no-inputs  found"  remind  the  analyst 
that  he/she  has  unresolved  problems.  If  the  problem  is  resolved  the 
memo  is  disassociated  from  the  output  requirements  that  have  been 
satisfied  and  left  associated  with  unresolved  problems. 


B.1.4  SYNONYMS  (SYN).  All  LARE  PROCESS,  and  MEMO,  INPUT,  OUTPUT  and 
ELEMENT  names  "were  given  SYNONYMS. 


SYNONYM  generation  must  be  consistent  if  it  is  to  be  effective.  Once 
a  SYNONYM  has  been  assigned  to  a  30-character  name  that  name  can  then 
be  referenced  by  the  shorter  synonym  string.  This  becomes  helpful 
when  loading  massive  updates  to  a  database.  It  was  also  effective,  in 
catching  instances  of  inconsistent  name  assignment  of  INPUT  and  OUTPUT 
elements  in  both  the  MOM  and  MPOM. 


SYNONYMS  were  derived  by  using  the  first  two  letters  of  an  analyst 
assigned  LARE  name.  For  example,  the  SYNONYM  for  "generate-wo-status- 
age- listing"  is  "gewostagl i . "  In  the  case  of  input  and  output 
elements,  two  synonyms  were  assigned.  One  was  a  Logi con-generated 
SYNONYM  for  the  ELEMENT  name.  The  other  is  the  Army-assigned  mnemonic 
for  data  elements.  For  example,  the  Logicon  SYNONYM  for  the  ELEMENT 
"identifyi ng-number-code-old"  is  idnucool".  The  Army  SYNONYM  is 
"ident-no-cd-old". 


B.1.5  ^OU!^^ J^f^) .  A  source  identifies  the  specification  and  the 
paragraph  number  from  which  a  requirement  is  taken.  A  SOURCE  is 
associated  with  a  PROCESS  or  MEMO  in  a  database  in  order  to  provide 
traceability  from  the  database  back  to  the  governing  specification. 
Each  AIRMICS  source  has  an  alphabetic  prefix  identifying  the  speci¬ 
fication,  for  example,  "m-"  denotes  the  MOM  specification.  Then,  the 
specification  paragraph  number  follows.  For  example,  MOM  Specification 
paragraph  number  3-7a(l)(a)  is  m-3,7.a.l.a  as  a  LARE  source.  "P-" 
denotes  a  MPOM  paragraph  number. 
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Source  references  extracted  from  the  various  specification  annexes  were 
coded  as  follows: 

m-a-i2.40.ky  fid. 5 


where 


m  =  the  specification  itself 
a  =  the  Annex  reference 

remaining  fields  -  represent  references  from  either  the  input, 
output, 

flowchart  or  decision  tables 


Thus  m-a-i2 .40.ky.fld.5  indicates  that  the  reference  is  from  Annex  A 
of  the  Maintenance  Operations  Management  Specification,  Float  File 
Adjustment  Input,  I2.40.KY  element  found  in  field  five  (5). 


Multiple  sources  are  allowed  for  a  single  object  name.  These  may 
occur  because  the  same  requirement  is  described  from  different  points 
of  view  in  two  or  more  different  sections.  Multiple  sources  may  also 
occur  because  a  single  requirement  statement  spans  several 
subparagraphs. 


B.1.6  DESCRIPTIONS  (PESO).  A  description  field  is  used  to  contain 
the  text  of  the  document  paragraph  from  which  the  requirement  was 
extracted.  A  description  may  be  attached  as  a  comment  to  a  PROCESS, 
MEMO,  INPUT,  OUTPUT  or  ELEMENT,  A  description  contains  a  maximum  of 
60  lines  of  text,  with  at  most  72  character  per  line. 


Descriptions  associated  with  data  items  contain  input  events,  output 
events,  input  and  output  control sj  (if  required)  and  in  some  cases, 
user  preparation  procedures. 


B.1.7  Attributes  (attr).  Attributes  were  used  to  specify  properties 
of  a  given  section.  Attributes  assigned  to  input/output  elements 
are;  field  length,  field  type  and  the  Lode  (the  corresponding  Annex  C 
reference).  Attributes  assigned  to  OUTPUTS  are  frequency  and  media. 
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B.1.8  DATA  AGGREGAIT^  Five  LARE  types  of  data  aggregates  were  used 
to  modeV'the  “MPOM.  They  are  SETS,  INPUTS,  OUTPUTS,  ENTITIES  and 
GROUPS. 


Three  LARE  types  of  data  aggregates  were  used  to  model  the  MOM.  They 
are  SETS,  INPUTS  and  OUTPUTS. 


B. 1.8.1  ^ET.  SETS  can  be  defined  as  physical  or  logical  views  of  the 
data  as  seen  by  the  user,  designer,  and/or  programmer. 


B.1.8. 2  INPUT  (INP).  An  INPUT  is  used  to  describe  a  collection  of 
information  produced  extenal  to  the  target  system.  An  INPUT  shows  the 
flow  of  data  from  the  outside  world  into  the  system.  Hence,  it 
crosses  the  system  boundary.  The  INPUT  section  is  also  used  to  uniquely 
identify  each  system  input. 


B.1.8. 3  OUTPUT  (OUT).  An  OUTPUT  is  used  to  describe  a  collection  of 
information  produced  by  the  target  system,  then  used  external  to  that 
system.  The  OUTPUT  section  is  used  to  show  the  flow  of  data  from  the 
sytem  to  the  outside  world.  Hence,  it  crosses  the  system  boundary.  It 
can  also  be  used  to  locate  and  uniquely  identify  each  system  OUTPUT. 


B.1.8. 4  ENTITIES  (ENT).  An  entity  is  a  logical,  usable  collection  of 
data  that  serves  a  unfque  purpose  within  the  system.  An  entity  is 
information  used  by  the  target  sytem  that  represents  an  object  or 
concept  internal  to  the  system.  It  is  required  by  the  system  for 
information  processing  purposes. 


B.1.8. 5  GROUP  (GR).  A  GROUP  is  a  logical  collection  of  data  elements 
and/or  other  GROUPS.  A  GROUP  is  a  collection  of  information  which  can 
be  contained  in  larger  collections  of  information.  INPUTS,  OUTPUTS 
and  ENTITIES.  For  example,  a  work  order  number  could  be  defined  as  a 
GROUP  containing  supporting  unit,  intra-shop  code,  year  and  sequence. 
It  was  not,"  it  was  instead  defined  as  an  element.  The  ELEMENT  (ELE) 
is  the  smallest  item  of  data  that  can  be  referred  to  within  the  system 
and  still  maintain  its  unique  properities. 


B.1.9  LARE  RELATIONSHIPS.^  As  the  LARE  objects  described  above  are 
the  "nouns"'  fn  the  syntax  of  the  User  Requirements  Language,  LARE 
relationships  are  the  "verbs".  The  definitions  of  LARE  relationships 
as  they  are  used  in  the  AIRMICS  application  appear  in  the  following 
paragraphs. 
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B. 1.9.1  PART,  SUBPART  (PART,  SUSP).  These  relationships  define  the 
position  of  a  PROCESS  in  the  process  hierarchy.  For  example,  process- 
work-orders  has  the  subparts  enter-i nitial-wo-data,  reconci 1 e-wo-parts, 
enter-wo-status ,  close-out-wo,  process-lookup-table-data,  work-order- 
transfer,  generate-work-order-data,  edit-transactions,  enter-parameter- 
data,  update-internal-wo-files.  Conversely,  it  can  be  said  that  the 
subparts  are  part  of  process-work-orders.  These  relationships  apply  to 
PROCESSES  only.  Each  PROCESS  may  be  part  of  only  one  higher-level 
PROCESS,  but  it  may  have  multiple  SUBPARTS. 

B.1.9.2  AI^1^ES,_  SEE-ME^MO  (^APPL^  SM)^  These  relationships  define  the 
connections  between  MEMOS  and  PROCESSES.  MEMOS  are  said  to  apply  to 
PROCESSES,  conversely,  PROCESSES  are  related  to  MEMOS  via  the  SEE-MEMO 
relationship. 

B.1.9.3  TRIGGERS,  TRIGGERED  by  (TRGS,  TRGS).  These  relationships  define  the 
flowchart  structure  in  the  execution  of  PROCESS.  If  one  PROCESS  TRIGGERS 
another,  this  means  that  the  second  PROCESS  is  exectued  after  the  first; 
conversely  one  may  write  that  the  second  PROCESS  is  TRIGGERED  by  the  first. 

B.1.9.4  UTILIZES.  UTILIZED  by  (UTIS,  UTLD).  A  PROCESS  that  can  be 
looked  upon  as  a  "subroutine^'’  of  another  PROCESS  and  in  this  sense 
subordinate  to  that  PROCESS,  handled  in  one  of  the  following  two  ways. 

If  the  “subroutine"  PROCESS  is  called  upon  only  once,  then  this 
PROCESS  is  TRIGGERED  first  and  it  in  turn  TRIGGERS  the  major  PROCESS. 

If  there  are  several  “of  these  “subroutine"  PROCESSES,  they  are  TRIGGERED 
in  turn.  However,  when  the  "subroutine"  PROCESS  is  called  upon  more 
than  once,  then  the  main  PROCESS  UTILIZES  the  "subroutine"  PROCESS 
although  it  may  TRIGGER  other  PROCESSES  itself. 

B.1.9.5  XNTEfiFAC^  INTERFACE  is  an  object,  organization 

or  system  outside  fheToundaries  of  the  target  system  that  interacts 
with  the  system  being  described.  It  identifies  the  origin  and  destina¬ 
tion  of  system  products. 

B.1.10  Data  Relationships  The  relationships  described  in  the  following 
paragraph  are  used  for  data  aggregates. 

B. 1.10.1  consists  of  ,  CONTAI^NE^D  Jn  ^CSTS,  CNTD) .  These  relationships 
define  how  data  items  are  organized  in  a'structural  hierarchy. 

ENTITIES  may  consist  of  GROUPS.  GROUPS  may  consist  of  other  GROUPS  or 
ELEMENTS.  ELEMENTS  may  not  consist  of  anything  else.  Conversely, 

GROUPS  may  be  contained  in  ENTITIES.  Other  GROUPS  or  ELEMENTS  may  be 
contained  in  GROUPS.  INPUTS  and  OUTPUTS  may  contain  GROUPS  and/or 
ELEMENTS  and  be  contained  within  SETS.  Nothing  else  may  be  contained 
in  ELEMENTS. 


81 


B.1.11  PROCESS/DATA  RELATIONSHIPS.  The  following  relationships 
define  actTions  wTTfclT  processes  perform  on  data  aggregates. 


B.1.11. 2  DERIVES,  DERIVED  BY  (DRVS,  DRVD).  A  PROCESS  derives  a  data 
aggregate  (conversely  the  data  aggregate  is  derived  by  the  PROCESS) 
when  it  completes  operation  on  data  it  has  obtained  and  puts  out  a 
changed  data  aggregate.  If  the  data  internal  organization  is  changed 
by  a  PROCESS,  a  new  data  aggregate  (with  a  different  name)  is  considered 
to  be  derived  by  the  PROCESS.  In  this  case  one  data  aggregate  is  used 
by  the  PROCESS  and  another  derived. 


B.1.11. 3  UPDATES,  UPDATED  BY  (UPDS,  UPDD).  A  PROCESS  UPDATES  a  data 
aggregate  when  it  changes,  expands  or  deletes  information  in  that  data 
aggregate  without  changing  its  basic  nature.  The  name  of  the  data 
aggregate  remains  the  same  and  no  new  data  aggregates  are  created. 


B.2  LARE  REPORTS 

This  section  gives  introductory  descriptions  of  the  LARE  reports  which 
have  been  most  commonly  used  by  analysts  for  this  AIRMICS  applications. 
These  reports  are; 

Formatted  Problem  Statement  (FPS) 

Structure  Report  (STR) 

Contents  Report  (CONT) 

Name  Generation  (NG) 

Name  List  (NL) 

Process  Chain  (PC) 

Data  Process  (OP) 

In  addition  to  the  report  descriptions,  the  formats  of  input  files  and 
modification  files  needed  to  build  and  maintain  the  databases  are 
di scussed. 

It  is  worthwile  to  emphasize  the  fact  that  since  the  content  of  any 
report  is  simply  a  reflection  of  the  infonnation  which  has  been 
prepared  by  the  analyst,  considerable  attention  should  be  paid  to 
preparation  of  input  files.  Subsequently,  fewer  errors  will  be 
encountered  during  input  and  reports  will  contain  correct  and  useful 
information. 


B.2.1  FORMATTED  PROBLEM  STATEMENT  (FPS).  This  report  makes  available  all 
names  and  relationships  associated  with  a  name  (or  with  a  list  of  names  in 
a  file)  specified  in  the  command  line  which  generates  the  report.  The  format 
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of  the  command  is: 

fps  n  =  process-work-orders  where  n  =  individual  data  base  name 


or 


fps  f  =  wo.inp  where  f  =  file  name  containing  a 

collection  of  names 

where  wo.inp  is  the  name  of  the  file  segment  containing  a  list  of 
database  names  for  which  formatted  problem  statements  are  to  be 
generated. 

Figures  B-1  and  B-2  provide  examples  of  FPS.  Figure  B-1  was  produced  by 
entering  the  command: 


fps  n  =  process-work-orders 
Figure  B-2  was  produced  by  entering  the  command; 
fps  f  =  wo.inp 

where  the  file  name  wo.inp  contained  the  names  of  the  five  ELEMENTS  shown. 
Figure  B-3  shows  an  FPS  and  the  input  file  that  generated  the  listing. 


B.2.2  STRUCTURE  REPORT  (STR).  This  report  gives  an  hierarchical 
structure  of  the  PROCESS  names  in  the  specified  database.  The  user 
has  the  option  of  including  in  the  report  MEMOS,  SOURCES  and/or 
relationships  by  which  other  names  are  associated  with  the  PROCESS 
names  present  in  the  structure.  Frequently,  the  analyst  is  interested 
in  only  a  subset  of  the  information  in  the  database-,  the  capability  to 
produce  a  structure  report  on  such  subsets  exists.  The  LARE  command 
is; 


str 

At  this  point,  the  program  requests  the  user  to  enter  NAME,  DEPTH,  and 
OPTIONS.  The  NAME  parameter  can  be  any  process  name  in  the  database 
whose  SUBPARTS,  to  a  specified  DEPTH,  will  be  reported  in  structure 
format.  The  DEPTH  parameter,  therefore,  requires  an  integer  represent¬ 
ing  the  number  of  levels  of  SUBPARTS  desired.  Entry  of  a  zero  ((3) 
for  the  NAME  parameter  implies  that  a  full  structure  (i.e.,  all 
process  names  included)  is  required  and  entry  of  a  zero  for  DEPTH  will 
give  all  levels  of  SUBPARTS.  Values  for  the  OPTIONS  parameter 
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Figure  B-1.  Sample  Formatted  Problem  Statement 
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Figure  B-2.  Sample  Formatted  Problem  Statement  Output 
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are  one  or  more  of  the  following: 

r  (include  source  references) 
m  (include  memos) 
a  (include  all  associated  names) 
p  (none  of  the  above,  include  process  names  only). 

Two  examples  of  valid  responses  to  the  program's  prompt  are; 

00  r  m 


or 


your-process  4  ra 


See  Figures  B-4,  B-5,  B-6.  Figure  B-4  shows  the  structure  of  all 
levels  under  enter-i ni  :i al -owo-data  printed  with  the  "p"  option. 
Notice  that  one  of  its  subparts  is  enter-standard-wo-data  which  has 
eight  subparts  itself.  Figure  B-5  is  a  structure  generated  with  this 
name  and  the  "a"  option.  It  therefore  includes  all  names  related  to 
each  of  the  eight  subparts. 


Figure  B-4  was  produced  by: 
str 

enter-i niti al-wo-data  0  p 


Figure  B-5  was  produced  by: 
str 

enter-standard-wo-data  0  a 


Figure  B-6  was  produced  by; 
str 

enter-i ni ti al -wo-data  0  r 


Figure  B-3  shows  an  FPS  and  the  input  file  that  generated  the  listing. 
And  as  shown,  MOM  paragraph  references  are  included,  as  well  as  all 
SUBPARTS  (or  subprocesses)  enter-initial-wo-data  and  enter-standard-wo- 
data  , 


87 


C  O  C  iJ 


W  O  W  1-  c 
Oi  I  D 


OtiorsOUiTTVS 

»Ju»i/»4jT>'T'0»-»*-» 


■:7  .3  u  n 

41  c:  O'  • 


T<o:3vr'c.'-jirt'3t4''C«->*-»* 


w>*_»rou'~'t)T3 
j»  u  f  »  o  •  n 


c  (J  c. 

*->  O  4'  c 

oj  w  t:  — • 
r:  •-#  '_»  I 
•  U  'D  •-> 


«  c  TJ  c  .1  :j 


-j  iX  *  tJ 


Ol  3"J*/»C 


’  «-<  W  ( 


I  o  c  c  3  e  I 


k.w'i}inw<u.4-»i 

'TCI  4<  .1  I 


*/>  o  v:  T  . 


n  I  t  .^  . 


4;  0*  4^  o 


^  o  >-•  ko  .«  u  :j  4;  u  13  0  n  r-  • 


•r  I  :2  <r 


-n  i-.  a>  t 


n  c  n  t  I  vt  u  u  ^  i 


j  o  o  '3  o  t: 


-♦  C-  I  o  o  lo 


.«  4/  C  T*  • 


I  V*  U  t>  •  Cj  • 


C  k-  (U  c. 


4  •/)  4'  «  !>  4^ 


^OTCCkfl#  I  \A  *-> 


C  k.  1/1  I/)  C 


t.:  W.  4J  fT  .o  D 


t  W 


X  a  4/ 

o  ^  e 


O  T’  • 

IX  I  U 
I  t  r  kJ 
X'  lA 
t)  — •  •;> 
k.  -4  T! 
v.  .'J  • 

«  r  'j 

w>  I 


I  •  UtWk-. 
X  X  Cb  4'  k4. 


o  •£>  •£•  c:  k-  t.  v«  >  t-.  k. 

4^  4/  <b  Oj  X  D 


c  n  ;r»  />  t_ 


I 


— *  fv#  O  I 


'  r>4  rry  ^  ^  .0  , 


^  ^  r>i  <•'4  • 


I 


8H 


Figure  B-4.  Sample  Process  Structure  with  the  "p"  Option 


Figure  B-5.  Sample  Process  Structure  with  the  "a"  Option 


Figure  B-6.  Sample  Process  Structure  with  "r"  Option  Only 
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and  as  shown,  MOM  paragraph  references  are  included,  as  well  as  all 
subparts  (or  subprocesses)  enter-initial-wo-data  and  enter-standard-wo- 
data. 


B.2.3  Contents  Report  (CQNT).  The  Contents  Report  gives  a  structure 
of  data  names  (as  contrasted  with  process  names).  The  INPUTS  to 
"contents"  must  be  ENTITY  or  GROUP  names  because  these  are  the  objects 
which  consist  of  other  GROUPS  or  of  ELEMENTS.  An  example  of  a  Contents 
Report  appears  in  Appendix  D,  Figure  D-4. 

cont  n  =  mpom-internal-data 


or 


cont  f  =  your-file 

are  examples  of  valid  commands.  The  file  your. file  would  usually 
contain  several  entity/group  names. 


B.2.4  Name-List  (NL).  Name  List  shows  alphabetically  every  name  in 
the  database.  An  example  NAME-LIST  appears  in  Appendix  D,  Figure 
0-8. 


B.2.5  Name-Generation  (NG) .  Name  Generation  is  a  useful  method  of 
creating  file(s)  containing  database  names,  to  be  used  as  inputs  to 
other  report  generating  programs.  The  user  controls  the  types  of 
names  to  be  included  by  specifying  values  of  a  selection  parameter. 
The  selected  names  will  be  extracted  from  the  database  and  put  into  a 
file  which  is  usually  used  as  input  to  other  commands.  The  format  of 
the  command  is: 

ng  s  =  "some  boolean  expression" 


or 


ng  s  =  "some  boolean  expression"  punch  =  your.fi le 


Inclusion  of  the  punch  file  parameter  is  optional.  Wiien  it  is  omitted,  a 
default  file  name  is  used..  The  selection  parameter  is  aesignated  by  the  "s" 
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The  general  forms  for  the  boolean  expression  are: 
"operand  operator  operand" 


or  simply 


"operand " 

Operands  are  legal  data  base  names  types  (process,  keyword,  etc.)  and 
operators  can  be  &  (AND)  and  (OR).  The  following  three  examples  of 
possible  command  lines  should  clairfy  this  description. 

ng  s  =  "process"  punch  =  proc.inp 
ng  s  =  "entity  group" 

ng  s  =  "process  i  keyword  =  m-5.8.c  "  punch  =  your.inp 

The  first  command  will  put  all  PROCESS  names  into  a  user  defined  file 
named  proc.inp.  The  second  command  wil  extract  all  of  the  database 
names  which  have  been  defined  as  either  GROUP  or  ENTITY  and  put  the 
list  into  a  default  file  in  the  users  directory.  This  command  also 
illustrates  the  method  of  using  the  output  file  from  ng  as  input  to 
another  command.  If  the  user  were  to  enter: 

cont 

following  execution  of  the  second  ng  example,  a  Contents  Report  would 
be  produced  giving  a  structured  list  of  the  contents  of  each  GROUP  or 
ENTITY  name  in  NG's  output  file. 

Following  execution  of  the  third  NG  example,  the  names  of  only  those 
processes  with  the  associated  keyword  m-5.8.c  will  be  extracted  from 
the  database  and  put  into  your. file. 

ng  s  =  some  process- inp 


or 


pc  f  =  some. inp 


B.2.6  Data  Process  (DP).  The  output  of  Data  Process  depicts,  in 
matrix  format,  the  relationships  between  data  and  processes.  A  data 
item  is  an  ENTITY,  GROUP  or  ELEMENT,  a  relationship  is  USES,  USED  BY, 
DERIVES,  DERIVED  BY,  etc.  The  report  also  includes  a  brief  analysis 
of  each  matrix  and  states  any  inconsistencies  in  the  data  flow. 

When  generating  this  report,  the  user  has  the  option  of  specifying 
either  data  items  or  PROCESSES  as  INPUT.  The  report  may  be  produced 
for  a  single  name  is  necessary. 
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To  generate  the  report,  enter  one  of  the  following  commands.  Note,  however, 
that  when  the  input  file  is  not  specified  in  the  command  line,  the  Data 
Process  will  assume  the  existence  of  Names-Gens’s  default  file  in  the  user's 
directory. 

dp  d 

dp  d  n  =  name-of-data-type 
dp  d  f  =  your.fi le 

The  'd'  in  the  above  commands  implies  that  data  item  names  are  being  used  as 
input  so  the  program  will  then  search  the  data  base  for  the  related  PROCESSES 
to  generate  the  matrices. 

When  the  user  enters  on  of  the  following  commands 

dp  p 

dp  n  =  process-name 
dp  p  =  your. file 

The  program  expects  to  receive  process  names  from  the  input  and  will  then  find 
An  example  Data  Process  report  appears  in  Appendix  D,  Figure  D-5. 


B.2.7  Input  Files  (IP).  The  content  of  input  files  will  vary  depending  upon 
whether  the  analyst  is  in  the  early  stages  or  later  stages  of  data  base  develop¬ 
ment.  Typical  early  stage  input  consists  of: 

PROCESS  names 

SOURCES 

MEMOS 

DESCRIPTION  statements. 

An  example  will  best  illustrate  the  required  format  of  input  files. 

Assume  that  several  requirements  are  known,  some  of  which  are  sub-requirements 
of  others.  Name  them  process-la,  process-lb,  process-2a,  process  2-b,  etc. 

Now  let  their  respective  B5  paragraph  references  be  k-la,  k-lb,  k-2a,  etc.  It 
may  also  be  necessary  to  input  text  which  describes  someof  the  requirements, 
such  as  MEMOS.  All  of  this  information  must  then  be  entered  into  the  database 
base  in  a  structured  manner.  Examine  the  following  input  (IP)  file.  This 
general  format  is  required  for  correct  data  entry. 

Later  stage  input  involves  using  all  of  the  CADSAT  name  types  and  relationships 
which  are  valid  for  AIRMICS  application.  Analysts  set  up  relationships  (such 
as  TRIGGERS)  between  PROCESSES  allowing  data  flows  and  process  chains  to  be 
defined. 
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B.2.8  Modification  Files.  There  are  four  types  of  database  modification  files 

DPSL  (Delete  Problem  Statement  Language) 

DEL  (Delete) 

REN  (Rename) 

CT  (Change  Type) 

B.2.9.  DPSL  Files.  The  format  of  DPSL  files  is  identical  to  that  of  ip  files 
but  are  used  to  "disconnect"  relationships  between  names.  Consider  the 
following  dpsl  file: 

prc  process-la, 
key  k-la, 
subp  process-x, 
eof , 

After  DPSL  processes  the  above  input,  the  keyword  k-la  is  no  longer 
associated  with  process-la  and  process-x  is  no  longer  a  SUBPART  of  process-la. 
However,  all  three  names  still  exist  in  the  database.  The  form  of  the 
command  is 


dpsl  f  =  your.inp 


B.2.10  DEL  Files.  The  format  of  the  Delete  command  is  one  of  the  following: 

del  n  =  some  name 
el  f  -  some. file 

This  command  is  used  to  actually  delete  names  form  the  database  entirely  (and 
therefore  the  relationships  to  other  names).  The  form  of  the  input  file  is 
simply  a  list  of  data  basenames  to  be  deleted: 

some-process-la 
some- keyword 
some-process-b 
some- data  name 


B.2.11  Rename  Files.  The  format  of  the  Rename  command  is  one  of  the  following 

ren  p  =  old  name  n  =  new  name 
ren  f  =  some.fi  le 
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This  command  is  used  to  rename  objects  in  the  database  (you  may  also  want  to 
change  their  synonyms).  The  input  file  format  is: 

old- name- a  new- name- a 

old-name-b  new-name-b 


B.2.12  Change  Type  Files.  The  change  type  command  is  either 
ct  n  =  some. name  t  *  new  type 


or 


ct  f  =  some. file  t  *  new  type 

Change  Type  is  used  to  correct  the  “type"  of  database  objects.  For  example, 
if  a  number  of  objects  were  mistakenly  entered  as  GROUP  names  and  should  have 
been  ELEMENTS  the  following  command  should  be  entered: 

ct  f  =  some.file  t  =  element 

where  some.file  contains: 

element-a 

element-b 

element-c 
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APPENDIX  C 

PROPOSED  LARE  ENCHANCEMENTS 


C.  INTRODUCTION 


This  study  and  other  previous  applications  have  found  LARE  an  effective 
methodology /tool  for  analyzing  and  defining  system  requirements.  Even 
though  Logicon  has  been  successful,  with  a  number  of  LARE  enhancements 
could  make  the  technology  even  more  effective  and  easier  to  use. 

Proposed  enhancements  have  been  grouped  into  three  categories:  specifi¬ 
cation  generation,  data  representation/display,  and  information  reporting. 


C.l  Specification  Generation 


One  of  the  chief  advantages  of  LARE  is  the  ability  to  generate  text 
specifications  directly  from  the  computerized  databases.  Enhancing 
the  capability  to  provide  the  following  is  desirable; 


C.1.1  Generate  Automatically  Maintained  Table  of  Contents 


The  ability  exists  to  generate  text  paragraph  numbers  automatically 
based  on  functional  hierarchical  structure  or  generate  the  text 
in  an  arbitrary  order  based  on  predefined  paragraph  numbers.  The 
missing  capability  is  to  generate  the  table  of  contents  including  the 
key  text  phrase  and  the  appropriate  page  number. 


C . 1 . 2  Develop  a  Generalized  Specifications  Generation  Language 


Logicon  has  generated  text  for  system  specifications  in  several 
different  formats.  Changing  the  format  requires  software  adaptation  of 
the  specification  generator.  What  is  desired  is  a  simple  specification 
generation  language  which  would  permit  the  user  to  define  the  specifi¬ 
cation  format,  and  enable  the  use  of  specialized  symbols  embedded  in 
the  text  to  control  printing  format.  The  capability  should  include  the 
option  to  indicate  specific  terms  for  inclusion  in  an  index. 
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C . 2  Data  Representation/Display 


The  presentation  of  information  could  be  improved  to  aid  the  analyst  in 
understanding  relationships  among  requirements  the  inconsistencies  or 
incompleteness  of  the  requirements.  The  following  presentation  im¬ 
provements  have  been  identified; 


C.2.1  Upgrade  Process-Chain  Report  to  Provide  Relational  Control 
Mow 


The  Process-Chain  Report  should  include  an  option  to  allow  display  of 
control  flow  relations,  whether  explicit  or  implicit,  at  any  level 
of  a  functional  hierarchy.  This  capability  will  allow  the  analyst  to 
identify  loops  and  logic  errors.  With  the  example  in  Figure  C-1,  the 
user  could  specify  "Level  =1"  and  have  the  Process-Chain  depict  control 
flow  at  the  highest  level  of  the  functional  hierarchy  (X  TRIGGERS  Y, 
in  the  example)  even  though  the  relationship  is  implicit.  This 
would  allow  the  analyst  to  look  at  any  level  of  the  functional  hierarchy 
without  losing  information. 


C .2 .2  Improve  Reports  to  Provide  Relational  Data  Flow 


This  modification  would  impact  the  Data  Process,  Extended  Picture,  and 
Process  Input/Output  Reports.  The  most  natural  technique  for  imple¬ 
menting  this  modification  would  infer  existence  of  d^ta  flow  relation¬ 
ships,  which  are  specified  at  any  level  of  functional  hierarchy, 
into  all  higher-level  functions.  Thus,  with  the  example  in  Figure  C-2, 
the  USES/DERIVES  relationship  would  be  inferred  by  LARE  to  apply  to 
functions  X  and  Y.  (in  addition  to  their  subparts).  This  modification 
improves  the  visibility  of  data  flow  relationships. 


C . 2 . 3  Augment  Reports  to  Provide  Relational  Data  Structure 


This  modification  would  affect  the  Data  Process,  Extended  Picture,  and 
Process  Input /Output  Reports.  Whenever  a  data  name  is  specified 
with  a  data  flow  relationship,  all  lower  levels  of  the  data  name's 
hierarchy  should  be  included  in  the  relationship. 
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PROCESS  X;  PROCESS  Y; 

SUBPARTS  XI,  X2;  SUBPARTS  Y1 ,  Y2; 


PROCESS  X2; 
TRIGGERS  Yl; 


=  control  flow  depicted  by  Process-Chain 
=  control  flow  not  depicted  by  any  report 


Figure  C-1.  Example  of  Control  Flow  Anomaly 
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PROCESS  X 
SUBPARTS  XI,  X2; 


PROCESS  Y 
SUBPARTS  Yl,  Y2; 


PROCESS  XI, 
USES  A; 
DERIVES  B; 


PROCESS  X2; 
USES  C; 
DERIVES  D; 


Figure  C- 


PROCESS  Y2 
USES  B,  U; 
DERIVES  Q; 


PROCESS  Yl; 
USES  D; 
DERIVES  U; 


explicit  data  flow 
impl icit  data  flow 


.  Example  of  Data  Flow  Anomaly 


LOGICON _ 

C.2.4  Add  Condensed  Listing 


A  condensed  listing  option  would  allow  the  user  to  format  pictorial 
reports  in  listing  form.  This,  nwdi fication  in  conjunction  with  a 
pictorial  report,  could  guide  the  analyst  in  identifying  links  across 
page  boundaries  or  it  could  be  used  independently.  Unlike  long  pictorial 
reports,  the  condensed  listing  report  is  easy  to  follow.  Figure  C-3 
shows  one  possible  fonnat.  Its  corresponding  system  diagram  is  shown  in 
Figure  C-4. 


C.3  lltoniia^tion  ^Reporting 


There  are  several  circumstances  in  which  the  handling  of  relevant 
information  is  awkward  and  the  information  not  readily  available.  The 
following  recommended  enhancements  are  of  this  type; 


C.3.1  Enhanced  to  NAME-GEN  to  Provide  Source  References 


NAME-GEN  should  be  extended  to  generate  a  list  of  all  reference  numbers 
contained  in  the  database  within  a  given  interval  (i.e.,  3.2.1.  - 
3.2.7).  This  would  simplify  completeness  checking  during  specification 
analysis  and  generation.  In  general,  it  would  be  helpful  if  users 
could  supply  alphabetic  or  numeric  ranges  of  objects  to  be  selected  by 
NAME-GEN  for  use  by  additional  report  generations. 


C.3. 2  Expand  Contents  Reprots  to  Provijde  Source  References  for  Data 
Types  -  -  -  -  -  . 


The  LARE  Contents  Report  should  be  extended  to  allow  data  structure 
reports  similar  to  the  Logicon  Extended  Structure  Report.  The  Contents 
Report  should  present  SOURCE  references  for  each  data  type,  in  addition 
to  the  relationships  appropriate  for  data  (DERIVED  BY,  UPDATED  BY, 
etc.).  This  extension  would  consolidate  information  now  contained  in 
separate  LARE  reports. 


C.3. 3  Expand  Triggers  Relation  to _All_ov^Bqq^l_e^n  C£nd it i^q^ns 


LARE  should  be  augmented  to  handle  conditional  control  flow  and  Boolean 
conditions.  This  feature  would  increase  LARE's  ability  to  accurately 
record  specification  information. 
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Figure  C-4.  Control  Flow  Diagram 


LOGICOM 


This  feature  increases  CADSAT's  ability  to  accurately  record 
specification  information. 


C . 3 . 4  Add  Source-relationship  Tags 


Neither  relationships  (USES,  DERIVES,  etc.)  nor  conditions  can  have 
SOURCES  attached  to  them.  Develop  an  ATTACH  statement  which  attaches 
a  SOURCE  name  to  anything  in  the  database.  No  strong  need  for  this 
modification  has  been  uncovered  by  this  study,  but  the  feature 
would  have  been  used  if  it  had  been  available. 


C.3.5  OBSTATUS  Short  Form 


The  DBSTATUS  report  needs  a  short  form  which  includes  only  the  sources, 
names  and  index  value.  This  report  could  produce  the  “table  of 
contents"  for  the  structure  report  at  less  expense  than  the  current, 
full  DBSTATUS  report. 
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Sample  LARE  Outputs 


D.  INTRODUCTION 


Eight  of  the  typical  LARE  reports  used  in  the  performance  of  the 
AIRMICS  study  have  been  included: 


•  STRUCTURE  -  structure  report  showing  the 

functional  hierarchy  of  the 
MOM  and  MPOM.  (Figures  D-1 
and  D-2) 


•  CONSISTS  MATRIX  -  matrix  and  listing  detailing 

those  elements  contained  in 
specific  inputs  in  the  MPOM. 
(Mgure  D-3) 


t  CONTENTS  -  report  showing  data  structure 

relations  in  the  MPOM. 

(Figure  D-4) 


•  DATA  PROCESS  -  this  report  depicts  in  matrix 

format,  the  relationship 
between  data  and  processes. 
(Figure  D-5) 


•  DATABASE  STATUS  -  report  showing  the  status 

of  each  requirement  and  the 
types  of  relations  defined. 
(Figure  D-6) 


•  FORMATTED  PROBLEM 

STATEMENT  -  report  depicting  all  of  the 

information  in  the  database 
for  the  specified  items. 
(Figure  D-7) 
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report  showing  all  names 
In  the  database. 

(Figure  D-8) 


Figure  D-1.  LARE  Process  Structure  of  the  MOM 
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Figure  D-1.  LARE  Process  Structure  of  the  MOM  (Cont'd.) 
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Figure  D-1.  LARE  Process  Structure  of  the  MOM  (Cont'd.) 
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Figure  D-1 .  LARE  Process  Structure  of  the  MOM  (Cont'd.) 
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Figure  p-3.  Sample  LARE  Consists  Matrix  (MPOM) 
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